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ABSTRACT 


The requirement to monitor a field operator's vital 
signs and location was articulated through the Counter 
Narcoterrorism Technology Program Office. The initial 
concept was to equip a "soldier" with a blue force tracker 
like device, which would be able to monitor and transmit the 
person's life signs, as well as their positional 
coordinates. 

This thesis focuses on the development of BioRAPIDS 
(Biomedical-Remote Automated Position Identification 
System), a capability within a broader sensor management, 
net-centric, system of systems to monitor, transmit, and 
display Heart Rate and GPS location. A spiral developmental 
model was implemented in order to select and integrate 
components, conduct testing, and provide feedback to the 
process. Based on system requirements, Commercial-off-the- 
Shelf/Government-off-the-Shelf (COTS/GOTS) components were 
chosen and adapted to meet the required interfaces. 
Component and subassembly interactions were then modeled 
using Integration Definition for Functional Modeling (IDEFO) 
modeling language to ensure traceability between functions 
and components. 

The culmination of the 10-month project was the 
creation of a system; starting at the idea phase through the 
delivery of a proof-of-concept prototype. Accompanying the 
created system is this thesis, which documents the 
development process, records testing analysis, and captures 
potential future courses of action. 
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I. SPONSOR NEEDS AND REQUIREMENTS 


This thesis documents the creation and development 
process of a system called BioRAPIDS. The system monitors 
and reports the bio-status and Global Positioning System 
(GPS) location of deployed troops to provide a commander 
with greater situational awareness of troops' operational 
status. The provided capability enhances the commander's 
ability to manage deployed forces and make more informed 
descisions. 

Aside from providing positional information, the bio¬ 
status reporting will give an immediate picture of 
casualties during combat, and with appropriate analysis can 
assist in understanding fatigue and physical stress on field 
troops. As all the available information is synthesized, 
strategic decisions can benefit from knowing troop strength 
levels, number of casualties, and location of forces; and, 
risk can be better assessed with real time information. 

Although mainly addressing this capability in a 
military context, this system's functionality is applicable 
to law enforcement, first responders, and commercial 
exploration, since personnel are deployed away from a 
central control point and their location and health status 
are of great interest. The Counter Narcoterrorism 
Technology Program Office (CNTPO) echoed the benefit of the 
enhanced situational awareness provided by the bio-state 
information of deployed troops and sponsored the development 
of BioRAPIDS. The U.S. CNTPO has the lead for developing 
technology for interagency and multinational operations to 
disrupt, deter, and deny narcoterrorist activities in an 
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effort to reduce trafficking in illegal narcotics and 
materials that support global terrorist activities. The 
CNTPO provides all federal government agencies with a rapid 
response-contracting vehicle that can award work quickly to 
support any counter-narcotics or counter-narcoterrorism 
operation or program anywhere in the world (domestic 
included). The sponsorship from CNTPO not only provided 
financial assistance, but also validated the system's 
relevance in today's world. The capability to track an 
individual's/team's health status and location during an 
operational mission greatly enhances the overall 
understanding of an operational situation and gives valuable 
input for choosing future courses of action. For example, 
if during a specific operation casualties are incurred, the 
operators at headquarters can immediately detect the number 
and location of possible casualties on the field; and, 
direct reinforcements or launch a SAR mission without 
waiting for reports from the ground. 

The CNTPO requirement was to provide a system that 
would, as outlined above, measure and report a field 
operative's heart rate and geographic location within a 
defined concept of operations. 

In response to this requirement, a system called 
BioRAPIDS was conceived within the Naval Postgraduate 
School's Cooperative Operations and Applied Science & 
Technology Studies (COASTS) Program (details on COASTS 
Program are in Chapter II). 

BioRAPIDS uses a heart rate monitor, which through a 
GPS enabled tactical radio connects the remote user to a 
local and/or remote data management/fusion network called 
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RAPIDS. The system allows anyone on the network with an 
installed RAPIDS client to push and pull information from 
attached sensors throughout the entire network, therefore 
linking together advantaged and disadvantaged users.^ One 
limitation to note is that the information sharing 
capability between the local and remote nodes^ relies on the 
ability to create a communication link between the two, 
which allows both nodes to transmit and receive information 
from each other. 

Each type of node will encompass an area in which 
installed sensors are within its communication umbrella and 
able to exchange data freely. Remote operational node's 
networks will depend on the range of the personal radios or 
similar short range communication links and devices to 
create this umbrella. Larger nodes, such as a command node, 
will have a larger umbrella in which to communicate and link 
devices since power and space limitations are usually not as 
restrictive as a mobile node. The key to an operational 
picture that encorporates the information from all nodes is 
linking all nodes together through a communication conduit. 
BioRAPIDS provides the sensors at a remote/deployed node and 
backhauling that is necessary to make it pertinent. 

The transition from a concept to an operational system 
required a clear understanding of the requirements so that 
the development process was efficient and the resultant 

^ The disadvantaged user includes dismounted troops, small platforms 
and distributed sensors. Key issues involve limited communications, 
processing power, power sources, and associated weight/space problems. 
Advantaged user is one that does not have such problems. 

^ Local and remote nodes are not absolute terms for location as it is 
relative to a particular viewpoint. For example, a local node can be the 
command node and the remote nodes would be the deployed sensors 
reporting to it. 
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product accurately addressed the needs of the sponsor. To 
properly understand the requirements they were viewed from 
two perspectives, the technological and the operational. 
Both had to be in synch for the system be a viable 
operational system and not merely a "cool gadget". During 
the design of BioRAPIDS, an operational CONOPS was used to 
determine physical requirements and was always at the 
forefront of consideration when selecting components and 
integrating lower level sub-assemblies. The aim of the 
BioRAPIDS thesis is two-fold. First is to develop a proof- 
of-concept prototype in conjunction with the BioRAPIDS 
contract parties. Secondly is to document the development 
process and provide an analysis of the end product and the 
process itself. 

To aid in the design process, many different inputs 
were considered to produce a more comprehensive prototype. 
The system's technological requirements based on the 
sponsor's needs and constraints were considered up front; 
and, the operational CONOPS was used to determine the 
physical requirements of the system. Once all the 
requirements were compiled, the plausibility of developing 
the desired system was analyzed to ensure that it was 
reasonable and feasible to expect the required functions 
from the proposed system under the anticipated operational 
context. 

The following sections of this chapter expand on the 
operational and technical requirements, discuss the thesis 
organization, and elaborate on the benefits provided by the 
BioRAPIDS system. 
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A. CONCEPT OF OPERATIONS 

By developing a concept of operations up front, some of 
the intrinsic requirements are taken into consideration when 
developing, integrating, and choosing components. The two 
most important requirements that were gleaned from the 
CONOPS document are the system ruggedness and form factor 
requirements. In a bottom-up design approach, CONOPS 
requirements are often not taken into account at the early 
stages of development and design. One lesson learned while 
conducting research into similar technology led to a project 
being conducted through a U.S. Army research lab. Although 
their approach was different from the BioRAPIDS approach and 
involved a complete bottom-up design of all components, many 
lessons were learned from their efforts. The project is 
named BIOMTX^ and is being developed to report blue force 
tracking and bio-status information of SOF. Their team 
shared the great technical strides that had been made and 
the positive results viewed in a laboratory environment. 
However, during their first field-testing event with those 
that were intended to be the users, the lack of extensive 
consideration of the physical requirements was clearly 
evident. The system did not have a realistic consideration 
of how the system would impact the end user. While form 
factor had been considered to the extent of it being an 
isolated system, the form factor did not accurately consider 
that it would have to be incorporated with the existing gear 
carried by heavy-laden combat troops. Relatively minor 
design issues, such as where the sensor was placed in 


^ For more information on BIOMTX, please contact the transition POC: 
Maj Kamil Asif, USSOCOM/SOAL-II-NSS. 
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relation to the straps of a soldier's pack or the placement 
of his rifle, came to light. Since this system was being 
developed under a different model from BioRAPIDS, form 
factor and CONOPS considerations were to be incorporated at 
a later date, which raises both the cost and time required 
for final development. The BIOMTX project was working under 
this bottom-up approach and therefore the consideration of 
physical requirements was acceptable, and the cost and time 
associated with this approach were inherent of that process. 

In contrast, the BioRAPIDS project was being conducted 
on a more compressed timeline and a reduced budget. To meet 
these constraints, BioRAPIDS used input obtained through the 
assistance of U.S. Army Special Operations Research and 
Support Element (SORSE) representatives who were 
participating in the Naval Postgraduate School's COASTS 
program. This invaluable input was used to create a 
realistic CONOPS and to refine system component selection so 
that the end product would be in line with the proposed user 
as well as meet the sponsor needs. 

The mission profile developed for CNTPO is not 
exclusive to the CNTPO mission. Since CNTPO's mission is to 
develop technology for interagency and multinational 
operations, the CONOPS is clearly applicable to a broad 
range of applications and participants. The scenarios 
themselves can best be described as part military special 
operations, part law enforcement, and is organized around 
small units, which often operate in remote harsh 
environments. The need for obtaining timely, accurate, 
processed health and location information from disparate 
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nodes is crucial in formulating a complete situational 
awareness picture. 

The following three scenarios are situations that were 
indicative of the potential operational use for BioRAPIDS. 
These scenarios were not meant to be all inclusive of every 
potential situation that the system could encounter, but 
were used as a core representative resource. Throughout the 
development of BioRAPIDS the possible application of the 
system were continually examined to ensure that as many 
possible conditions were addressed to maximize the 
deliverable prototype's capability. The result was a more 
robust prototype and a reduction in cost and time required 
to produce it. The scenarios listed below follow the 
progression of one operation; each scenario builds upon the 
previous scenario. As the operation develops, different 
uses for BioRAPIDS come to light 

1. Field Patrol Scenario 

Based on intelligence reports, a determination is made 
that suspicious activity is occurring around a remote 
village in country Blue.^ There has been an increase in 
vehicle traffic in and out of the area and imagery has 
located an increase amount of activity around two buildings 
that are presumed to house a cocaine processing facility and 
storage for illicit weapons. A squad of Marines is tasked to 
patrol the area and conduct reconnaissance to verify the 
true nature of the increased activity in the area. The 
squad consists of 13 Marines with a Navy Corpsman. 

Colors are used as a reference for different participants in 
operational scenarios. Red is hostile, blue is friendly, and white is 
neutral. 
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While preparing to deploy, members don the BIORAPIDS 
device under their normal clothes. They then energize the 
transceiver and verify that they are transmitting a proper 
signal and it is being received at the command center. Once 
on patrol the Corpsman with a RAPIDS enabled UPC (Ultra- 
Mobile PC or other handheld in future versions) monitors all 
of the squad members. In case of an emergency, the corpsman 
receives visual or audio alerts based on the set points that 
he created so that he does not need to view the screen 
continuously. Back at the command center, another operator 
is able to keep a constant watch on the deployed personnel 
(each with a BioRAPIDS system), and through interpretation 
of the data is able to determine the level of exertion of 
the combined team. Any other interested party with a RAPIDS 
(RAPIDS is further defined in Chapter II) enabled client is 
able to monitor the progress of the team as well as view 
their health status if desired. 

2. Triage Scenario 

As the patrol closes the village, two separate teams 
from the squad are dispatched to investigate closer to the 
village. One team goes on the right flank, and as this team 
gets about 500m away, there are several explosions near the 
dispatched team (each team member is wearing a BioRAPIDS 
system) . As the corpsman heads in the direction of the 
team, he checks his display (monitors health status and 
location of the dispatched team) to notice one individual's 
alarm has been activated based on a zero heart beat rate 
detected, while another team member's BioRAPIDS system is 
rapidly approaching the high alert set point. Based on the 
information, the corpsman moves to treat the Marine who 



still has a heartbeat and stabilizes him. He then moves to 
the Marine who was showing no heartbeat and confirms that he 
is in fact a casualty from the explosions. At the command 
center, the watch stander notices a flash of his screen and 
then one of the Marine's icon turns red. Upon clicking on 
the red icon, he notices the heart rate at zero and 
correlates the information with the Corpsman on the scene. 

Based on the explosions, from the explosives set by the 
insurgents, the village is alerted to the Marines' proximity 
and a firefight ensues. The Marines call for cover fire as 
they retreat to the evacuation area. In the process, two 
more Marines receive small arms fire but are determined to 
not be in a life threatening condition based on the remote 
monitoring of their vital signs through the BioRAPIDS 
system. They maintain a steady heartbeat without nearing 
any of the alert set points. 

3. Remote Monitoring Condition Scenario 

Once inside the evacuation helicopter the corpsman 
begins to treat the two Marines that were shot. While the 
corpsman is treating the two Marines, the watch stander at 
the command center continues to assist the team by 
monitoring the rest of the squad. In a matter of seconds, 
he sees the heart rate of the Marine injured in the 
explosion rising rapidly. He quickly alerts the corpsman, 
who had not seen the alert while he was treating the other 
injured Marines. The back up from a Headquarter's node is 
of invaluable assistance to the corpsman who can not monitor 
all personnel continuously while actively engaged in 
treatment of an injury. 
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The corpsman then begins to treat the Marine going into 
shock. He is able to stabilize him long enough to return to 
the base where the Marine receives further care. 

B. TECHNICAL REQUIREMENTS 

This section is an attempt to dissect the sponsor's 
need into high-level technical requirement descriptions of 
those needs (more detailed requirements are explained in 
Chapter III) . The process of developing BioRAPIDS started 
as a very informal one (similar to a "skunk works" approach) 
and the system requirements from the sponsor were vague. 
This allowed the development team wide latitude to explore 
several approaches prior to pursuing a particular course of 
action. This approach brought with it some benefits and 
drawbacks. On the positive side, the system development 
process was more creative, and perhaps a bit more "out of 
the box, " since it was not constrained by very specific 
initial requirements. The team also became more vested in 
the overall system development process itself, since the 
entire team was involved in a larger portion of the system 
development process for BioRAPIDS and not just their 
specific areas of expertise (such as only concentrating on 
software development or sensor acquisition). This approach 
also complicated the system development process slightly in 
that the development team did not have a clear path to 
pursue, so bounding the problem became an added task. 
Once the possible configuration of sensors, transceivers, 
and displays were narrowed to more specific ones, a clear 
path was agreed on by all parties, and detailed 
specifications were written for system components and then 
approved by the sponsor. Below is a high-level view of each 
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of the main requirements, which will be more technically 
expounded in Chapter III. 

1. Bio-Status Monitoring Requirements 

First and foremost was the needed capability to monitor 
an individual's heart rate. This was perhaps the least 
strictly defined portion of the requirements and would rely 
more heavily on available commercial off-the-shelf (COTS) 
technology. The main requirement was to use a commercial 
grade heart rate monitor, similar to any sports and fitness 
device that is readily available. The exact sensor 
capability relied on the sensor chosen since this was 
completely a COTS product. The second requirement was for 
the sensor to have an output capability that would interface 
with the radio for transmitting the data. The ability to 
ascertain an individual's mortality and/or health state 
gives a decision maker the capability to make more informed 
decisions. By having that information available in at least 
near real-time, a commander can assess how their unit's end 
strength has been affected by either casualties or physical 
stress. In a pre-assault stage, a commander can assess 
their force's suitability for a specific task and decide 
whether a tactical delay can enhance the probability of 
success, and better ascertain the risks involved with the 
trade-offs. In a Search and Rescue (SAR) situation, health 
state can assist in prioritizing operations. For a 

commander, this knowledge can assist in evaluating the 
urgency of a particular mission and aid in the process of 
evaluating risk and need. As a tool for the Medical 
community, the information can guide triage priorities in a 
multiple casualty environment and perhaps assist in 
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the 


preliminary remote diagnostic efforts. Therefore, 
sensors ability to measure vital signs and output the 
information accurately in real time were the most crucial 
requirements. With the technological requirements 

satisfied, the sensor must also meet the requirements posed 
by the designed CONOPS. The factors of size, weight, 
material, etc., were equally as important in the final 
component selection. Minimizing size and weight and 
maximizing ruggedness were paramount, and field tests were 
used to validate manufacturer performance claims. 

2. Transceiver Component Requirements 

Next, in the flow of information, is a method for 
transmitting the required data. The accurate and timely 
transmission and reception is an essential component of 
making the information actionable. Technology today allows 
sending and receiving numerous types of data seamlessly and 
with seemingly no delay. However, that same technology 
which connects everyday lives is not readily available or 
practical for field operations. Therefore, the second 
technical technical requirement is a transmission method for 
the health and positional data via a system that supports 
the disadvantaged user and meets the requirements of a 
decision-making node. 

While the BioRAPIDS system itself is designed with only 
a personal tactical radio, secondary transmission methods 
such as Iridium phones, BGAN satellite antennas, etc are 
able to be incorporated into the architecture to backhaul 
the information. The exact configuration for backhaul is 
mission dependant. 
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3. 


Data Management 


Although not explicitly relayed from the sponsor, it is 
an important assumption made that the raw BioRAPIDS sensor 
data requires adequate processing in order to provide value- 
added information. If the data is not organized and 
presented in a manner that the operator can quickly 
manipulate and understand, the system will cease to be a 
useful tool and will hinder the decision making process 
instead. "The capability of the human brain and the 
limitations to process the information transmitted by the 
system has to be considered. The amount of information 
transmitted and measured in bits can be unlimited. Unlike 
this, the capacity of the human brain only enables 
processing of a few bits of information. If a difference 
between the amount of information transmitted and the 
capability of what can be processed occurs, a miss-match 
between pilot and cockpit information system may be the 
result" (Lovesey, 1995). Similar to a cockpit, an operator 
in front of a display console can quickly become overwhelmed 
if required to process too much raw data. For example, if 
an operator is monitoring a battlefield operational picture 
with 25 soldiers transmitting BioRAPIDS data plus other 
sensor displays (cameras, radars, ground sensors, etc.), 
various vehicles maneuvering, and numerous radio calls, they 
are very quickly overwhelmed if the information was not 
properly organized. A balance must be found so that the 
information is filtered adequately to provide sufficient 
actionable information, but not bog down the decision-making 
process with irrelevant data points. 
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C. THESIS FOCUS 

In exploring the need presented by the sponsor, the 
main focus of this thesis is to explore a system configured 
to enhance situational awareness through multiple layers of 
command and control with the use of networked personnel 
monitoring devices. It is important to note that a desired 
technological capability does not necessarily address or 
support a need; technology for technology's sake is not an 
answer for an operational need, it merely shows the ability 
to do something. How the technology is implemented within a 
system determines whether the particular need is addressed 
by the technology. Therefore, the questions of what 
technology is developed and how it is implemented become 
equally important. While developing BioRAPIDS, the main 
purpose is to ensure that the system is designed, 
configured, and implemented to provide maximum benefit to 
the users. It also addresses the information gap in a 
manner that is complimentary to the end user and does not 
detract from his capability. 

Secondly, this thesis yields a working prototype of the 
BioRAPIDS system. Secondary research areas explored during 
the development process are to: analyze the system's 
capabilities and limitations; examine the development 
process of BioRAPIDS; study system performance in a variety 
of environments; and, propose future implementation and 
development based on the system findings. 

Although the analysis of the development process of the 
system is listed as a secondary research area, it is in 
practicality the basis for successfully answering the main 
thesis question. For BioRAPIDS to enhance situational 
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awareness, it is crucial to understand how it is designed 
and integrated and what it is capable of doing under varying 
conditions. The systems engineering process applied in this 
thesis, towards the "skunk works" type system development of 
BioRAPIDS, is closely detailed since it provides a way to 
assess adherence to requirements and efficiency of the 
process. 

The thesis itself is divided into three parts and 
composed of five chapters. Part I covers the thesis 
overview and is composed of two chapters. Chapter I 
discusses the need presented by the sponsor, and dissects 
the technical and operational requirements to meet the need. 
It also discusses the research questions being explored, and 
closes with an explanation of the benefits of conducting the 
study. Chapter II discusses the methodology used within 
COASTS for development and testing (discuss partnering with 
commercial vendors, field testing, demonstrating in a 
scenario based demonstration). It will slightly touch on 
RAPIDS and its influence on this project. Lastly, Chapter 
II will detail the systems engineering approach utilized in 
product development. 

Part II details the system evolution, and is supported 
by two chapters. Chapter III explains the functional and 
physical architectures and how they aid in ensuring that the 
system design requirements are met. Along with the higher- 
level architectures, functional decompositions, signal flow 
diagrams, interface design, and Operational architecture 
models help develop the lower level component subassemblies. 
Chapter IV will discuss in detail the various configurations 
used, explain the testing conducted at each iteration. 
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analyze testing results, and provide a chronological record 
of the iterative evolution of subassemblies based on testing 
results. 

Part III presents the results and conclusions of the 
thesis, in Chapter V. Based on results, this study will 
conclude with an assessment of utility of the current system 
model, identify shortcomings, and propose modifications and 
future development. 

D. BENEFITS OF THE STUDY 

The implications of the BioRAPIDS system, developed in 
this thesis work, to the Command and Control arena are 
numerous. The ability to track and monitor the health and 
location of teams and individual team members operating 
remotely, in real time, gives the warfighter an added layer 
of information with which to make decisions. The ability to 
know the health status of the team members allows the 
decision maker to assess mission success, alter tactics, and 
understand the limitations of a particular individual/team, 
based on the biotelemetry data received. 

On a larger scale, if all troops were outfitted with a 
device, higher-level commanders could deploy their forces to 
reinforce areas where there was a significant number of 
casualties, or to where the troops were simply low in 
stamina, based on the data provided by the Bio-telemetry 
device. In utilizing a Bio-RAPIDS device, troops will be 
able to push the information from their sensors, and if 
equipped with a display will also be able to pull the 
overall common operational picture; thus, bringing the 
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disadvantaged and advantaged users together in a net-centric 
world. 

The fact that this system will be created from 
(COTS/GOTS) technology makes it presumably more economical 
an easily scalable to other applications. If required, the 
system can be encrypted for specific applications, such as 
military operations; but could also be accessible to those 
without encryption requirements, such as commercial 
operations. 

A non-military, yet practical application of Bio-RAPIDS 
and RAPIDS can clearly be seen with recent wild fires 
throughout California. The benefits of having a command 
center that is capable of tracking the location of all 
deployed fire fighters in remote locations as well as their 
health status greatly enhances the ability of the fire chief 
to deploy his forces more efficiently and prevent 
endangering lives. He can effectively redirect forces based 
on fire movement, rotate firefighters based on fatigue, and 
overall minimize the risk to life of his firefighters by 
preemptively determining a potentially dangerous situation. 
This concept is also applicable to any first response based 
organization, law enforcement, commercial exploration, etc. 

E. IDEA REFINEMENT 

In order to give life to the ideas presented in this 
chapter, a framework is needed to guide the process. 
Chapter II of "Framework and Context" provides a contextual 
background for BioRAPIDS and explains the process used 
during the system development. It also provides the 
foundation for the technical development and is followed by 
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a description of the players and relationships 
within the BioRAPIDS development project. 


involved 
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II. SYSTEM DEVELOPMENT FRAMEWORK AND CONTEXT 


The intent of this chapter is to describe the 
foundation for the BioRAPIDS project. The three main 
sections will introduce the parties composing the system 
development team, give a brief introduction into the general 
systems engineering timeline toward system development, and 
delineate the specific approach used in creating BioRAPIDS. 

A. DEVELOPMENT TEAM 

The challenges in formulating a response to the need 
presented by the project sponsor are numerous in scope and 
complexity. In order to accomplish the various steps of the 
design process members of the development team worked to 
identify needed components, design integration tests and 
conduct system testing at various stages in the process. 
This thesis was done as a contribution to the design process 
both is technical contributions and an administrative 
documentary of the process. 

BioRAPIDS development was completed in conjuction with 
the Naval Postgraduate School (NPS) Cooperative Operations 
and Applied Science & Technology Studies (COASTS) 2008-2009 
program.5 COASTS is composed of NPS students and faculty in 
together with the Office of Naval Research (ONR) Navy 
Reservist, numerous commercial partners and international 
organizations. With NPS COASTS, as a combined team, the aim 
is to conduct a series of experiments and demonstrations of 


^ For more information regarding the COASTS Program, please contact 
Mr. Jim Ehlert in the Graduate School of Operational & Information 
Sciences at the Naval Postgraduate School in Monterey, CA. 
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emerging technologies, with BioRAPIDS being one of them, in 
the United States, Thailand, Singapore and Australia. Each 
year's cycle of field experiments implements a progressive 
approach to testing; beginning with individual technologies 
testing, followed by an integration of multiple systems. 
The cycle culminates in a scenario driven demonstration to 
display the applicability of each system (in a CONOPS based 
situation), integrated within a system of systems command 
and control architecture. 

Inside the framework of the COASTS program, Lockheed 
Martin Co., Electricore, Inc., Kestrel Technology Group, A3 
IT Solutions, Raveon Technologies and NPS students and 
faculty coordinated their efforts to produce Bio-RAPIDS as a 
response to the need posed by CNTPO, the project sponsor. 
The underlying aim of BioRAPIDS development is to leverage 
the contributions of all participants and adapt available 
Commercial of the Shelf (COTS) and/or Government of the 
Shelf (GOTS) technology in order to provide a cost-effective 
and functional solution rapidly, and meet the war fighter's 
needs. 

Lockheed Martin was assigned by CNTPO as the executing 
agent of the BioRAPIDS contract and oversaw the development 
process on their behalf. Electricore, Inc. served as the 
project manager and coordinated the acquisition of 
components, sub-contracting, and was overall in charge of 
managing the BioRAPIDS project. Kestrel Technology Group 
was the lead contractor for developing BioRAPIDS and 
directed integration efforts, software development, 
component research, and coordinated testing efforts. A3 IT 
Solutions was sub-contracted to develop the BioRAPIDS GUI 
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and assist in the integration of BioRAPIDS into the overall 
RAPIDS architecture. Electricore, Inc. also conducted 
transceiver development, with Raveon Technologies as a 
technical consultant. They modified an existing radio 
system, based on testing feedback, to develop the 
transceiver incorporated into the BioRAPIDS system. Lastly, 
NPS faculty provided a great deal of assistance in the 
initial selection of the components, technical document 
editing, and continued consultation during the development 
process; while NPS students provided input or direct support 
during the various stages of development, testing events, 
presented a proof-of-concept prototype and documented the 
process and results which are found in this thesis. 

B. GENERAL SYSTEMS ENGINEERING TIMELINE 

The complexity of developing an operational system is a 
daunting hurdle to overcome. In order to add organization 
and structure to this process, a systematic systems 
engineering approach was utilized. By having an outlined 
approach to the development process, it was assured that 
events were tracked and a coordination methodoly was used to 
align development efforts with the overall timeline. Figure 
1 shows the general timeline for the process, which will be 
used throughout the development of BioRAPIDS. Although this 
figure shows a linear timeline, the actual events were not 
necessarily always one dimensional in respect to time of 
execution, nor was any one phase mutually exclusive of 
another. The development process used for creating 
BioRAPIDS is a spiral model in which an iterative procedure 
of design, integration, and testing was conducted and 
feedback was used to create required modifications prior to 
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the next round of development. The iterative procedure 
continued until the final prototype was developed and 
delivered. However, the linear timeline model gives a good 
representation of the general progression of the project. A 
brief description of each phase follows in order to baseline 
future references to this timeline and to ensure a clear 
understanding of the progression of this project. 



Figure 1. General Systems Engineering Approach Timeline 

based on Time (X-Axis) and Cost (Y-Axis) (From: Dr. 

Lawrence Goshorn, JLG Technologies, Inc.) 

1. X Phase-The Need 

This phase is not at all technical and is mainly 
conceptual in nature. It is the phase when someone comes up 
with an idea, discovers a need, or perhaps identifies a gap 
in the technological capability of existing systems. It is 
where someone says, "wouldn't it be nice if we had something 
to do..." There are no bounds or constraints in this phase, 
as it is not technical in nature nor is it design related. 
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It merely creates an unevaluated wish for a particular 
capability. For BioRAPIDS, this came about at a COASTS 
Field Experiment (FEX) in 2007. An observing Special 
Operations Forces (SOF) member suggested that it would be a 
great capability to be able to ascertain a person's vitals, 
as well as his location while they were deployed. He 
explained that a large percentage of SAR missions were done 
to recover a service member that was already deceased, and 
it would be a good planning tool to know the individuals 
status prior to planning a SAR mission-in order to minimize 
risk and plan more effectively. The same sentiment was 
echoed by CNTPO, BioRAPIDS Sponsor, and the idea was then 
moved to the next phase of development. Typically, a need 
statement is generated to give bounds to the specific needs 
the desired system must meet. This is not necessarily 
technical in nature, but in plain text outlines what the 
capability gaps are, how a system can be beneficial if 
created, and what that system must do. 

2. A Phase-Concept Definition/Preliminary System 
Design 

This transition phase takes the broad idea and gives it 
definition. The intent in this phase is to formalize an 
idea into specific requirements, and to lay the groundwork 
for the technical development to follow. There is constant 
interaction between the phases preceding and following the A 
phase to ensure the project begins on solid footing. This 
phase generates the Originating Requirements Document (ORD), 
which will present the system in a more detailed manner as 
to the expectations of performance, functions, and 
operation. This document is based on the external systems 
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diagram, which shows how this particular system is expected 
to interact in a broader picture. Seen in Figure 2, and 
described in further detail in Chapter III, is the external 
systems diagram (ESD), which shows how BioRAPIDS will fit 
into a larger sensor management system. 


Connectivity and Network Program System Sensor 

Bandwidth Settings Settings Capabilities Capabilities 



RAPIDS Sensor 
Management/Fusion 
System 


Figure 2. BioRAPIDS External Systems Diagram 

Along with the ESD, the operations concept and an 
objectives hierarchy are the main components of the ORD. 

As with many of the phases of development, each action 
is not exclusive to only one phase of development. 
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Interacting with the sponsor at the X-Phase level may be 
required to clear up or modify requirements in order to 
properly transition a conceptual idea into a feasible 
technical product and meet the customer's needs. This 
glimpse into the technical feasibility of a product is 
explored in detail during the B-Phase to ensure that the 
requirements being sought are feasible. The interaction 
among the phases ensures that the requirements documented 
are in fact what the sponsor is envisioning, and also 
provides a technical sanity check into a preliminary top- 
down design to verify the feasibility of the proposed 
system. 

To complete this phase, it is important to conduct 
research into existing relevant systems that may have 
similar applications or components. In this instance, 
extensive research into existing systems or components is 
essential, as the system being created is an amalgamation of 
existing COTS/GOTS technology. However, even if the system 
were being completely designed and built from the ground up, 
it is extremely important to explore existing technologies 
to understand the current limitations, and perhaps avoid 
problems that have already been discovered in similar 
applications. By researching existing systems or 
approaches, one can more efficiently create a new system and 
leverage available information. 

The main documents generated from this phase were the 
requirements and specifications documents (Requirements, Sep 
2009), the project timeline (BioRAPIDS Schedule, Sep 2009), 
and the functional architectures hierarchy and 
decompositions (described in detail in Chapter III). 
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As discussed, this section required a lot of 
collaboration between the X, A and B phases in order to 
create an expectation that was attainable and would meet the 
requirements. All proposed configurations, schedules, and 
formal documents were vetted through the sponsor to ensure 
that the more formal depiction of BioRAPIDS was still in 
accordance with the expectations and needs of the customer. 

3. B Phase-Formal System Design 

This stage took the descriptions and requirements 
formalized in the A phase and created a technical design of 
the system. This phase is characterized by a bottom-up 
approach to designing the system where a detailed technical 
design of the system is created. This is then combined with 
the top-down description created in Phase A to ensure that 
all requirements are being met, and any required changes are 
approved by the sponsor prior to progressing into actual 
component acquisition and integration. 

The approach used with BioRAPIDS was slightly different 
in that components were not created from the ground up. 
Research into available components was done and the results 
ranked in respect to performance and cost. Overwhelmingly, 
cost was the deciding factor of the choices, so long as the 
component met the stipulated requirements. 

Once all the required functions were identified and 
mapped, the physical architecture hierarchy was created and 
signal flow diagrams were created to analyze integration 
points and interface architecture; and, an operational 
architecture was created to verify traceability between 
physical components and functional requirements. 
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Lastly, a testing requirements document was created to 
outline how the system's functionality was to be evaluated 
and demonstrated. This was not a change to the overall 
timeline presented earlier, but rather a detailed 
description of how the testing events would be conducted. 
The testing requirements document(Test Plan, Oct 2008) 
outlines the performance measures that are used and the 
particular focus of each testing event. 

4. C Phase-Component/Subassembly Acquisition and 
Implementation 

In a traditional system development process, the 
detailed components and interfaces designed in the B-Phase 
are manufactured in accordance to design specs in order to 
meet the requirements desired by the customer. This 
definition has a limited application to the way BioRAPIDS 
was created. Perhaps the only function that remained true 
to this phase was the creation of the GUI. Since this was a 
completely new application that was being introduced, the 
GUI was created from the ground up and therefore required a 
more detailed requirements and specifications determination 
process for its bottom-up design. It was, however, almost 
independent of the other subsystems and work could be 
ongoing while the procurement of the other components was 
being conducted. In order to prepare for a variety of 
possible sensors, the GUI was created with a great deal of 
flexibility, not only to accommodate the chosen sensor, but 
also to allow greater ease for future upgrades to more 
capable sensors. 

Other functions that are accomplished within this phase 
include the reengineering required of the radios, the 
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creation of interfaces, and to a lesser extent the 
improvisation of housings and other physical components. In 
a broad sense, this phase mostly entailed procuring the 
selected components from distributors. 

With the acquisition of commercial products there was, 
at times, a difficulty in gaining access to the products 
software development kit (SDK)/Application programming 
interface (API). Access to a particular sensor's or 
encoder's SDK was crucial in developing the needed interface 
between monitor and transmitter. 

5. D Phase-Integration and Testing 

In order to maintain consistency with the RAPIDS 
system, to which BioRAPIDS would be reporting, it was 
essential to standardize message formats, reporting cycles, 
network configurable parameters, and properly combine 
independent components to create viable interfaces. This 
phase is perhaps the most frustrating and takes quite a bit 
of time and rework to ensure that the independent components 
meld into a functioning system that properly interacts with 
the external systems. Based on the difficulties encountered 
during the integration process, adjustments were required to 

the functions performed during Phase C; and, in certain 
cases, required adjustments to portions of the A and B 
phases. 

It is important for Phase D operations to begin during 
Phase C. Any frontloaded integration work that can be done 
will result in much easier integration and a faster 
completion of the D phase. For example, if a device needs 
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to send its data to a second device for processing, but each 
product development was done in a vacuum and each device 
uses different I/O formats, the integration stage would be 
complicated by either rework of the I/O ports or determining 
a work around increasing cost and time required. During the 
development of BioRAPIDS, the team's choice of interfaces 
was limited to what was available with the chosen COTS/GOTS 
components. Inherent of the process of combining existing 
technologies in new applications, some minor alterations 
were made to interfaces, encasement, and data formats. 

On the field deployed end of the system, two equipment 
interfaces of concern were identified. One from the sensor 
to the processor and the other from the processor to the 
radio. On the command end of the system, the interfaces of 
concern were between the operator and the GUI. This was 
largely a software solution, but some hardware engineering 
was required in order to bring the remote sensor information 
into the command network. The integration of the BioRAPIDS 
system into the overall RAPIDS system architecture was the 
focus in moving BioRAPIDS from a stand alone system to a 
contributor of a larger scale command and control system of 
systems. The output from BioRAPIDS would have to be 
integrated and fused with the data from various other 
sensors. 

The goal at the end of this phase is to produce an 
operational prototype that has been tested as extensively as 
possible, so it can therefore be transitioned to a more 
mature system with only minor alterations. For BioRAPIDS, 
this phase will conclude in February 2010 when the final 
Alpha prototype system is tested, demonstrated, and 
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delivered to the project sponsor. Due to curriculum and 
project timelines not matching up, this thesis will only 
document up to the July 2009 field experiment. 

6. E Phase and Beyond-Documentation, Production, 
Life Cycle, System Retirement 

This thesis completed a portion of the E-phase, which 
encompasses documentation for the system. Additional 
documentation such as operating manuals, technical manuals, 
training manuals and other pertinent documentation will 
follow, as the system continues to mature. The rest of the 
development timeline covers the production period, 
operational life, system maintenance, and finally retirement 
of the system. Since the BioRAPIDS system is only funded to 
prototype development, these follow-on phases were not 
addressed by the development team nor have they been 
explored in any formal fashion within the thesis. 

C. BIORAPIDS DEVELOPMENT APPROACH 

The model utilized for developing BioRAPIDS was a 
spiral development approach (Figure 3) . This follows the 
progression of the general timeline with the added advantage 
of multiple iterations of the integration and testing 
phases. 
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Figure 3 


Spiral Development Model 


Essentially, if one would take the general timeline, 
detach phases B through D, and insert the spiral development 
model for phases B through D, one would have an accurate 
portrayal of the required development actions for BioRAPIDS. 
In both models, one can see that the early phases X-A and 
the latter phases E and beyond are not shown to be affected 
by the repeating design, development, integration and 
testing cycle. This is almost guaranteed in the case of the 
latter phases, E and beyond, since these constitute the work 
done once a final product is provided. As for phases X-A, 
they generally will not be affected in either model; 
however, if serious enough hurdles are encountered in the 
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development process, it could affect the core concepts of 
the systems. A simplified depiction of the iterative nature 
of the spiral process is seen in Figure 4. As one can see, 
the cyclical tasks of planning, designing and implementing, 
testing, and evaluation continues almost idefinitely and is 
only limited by the alotted system development timeline. 



Figure 4. Iterative Development Process 


The benefits involved with utilizing this model is that 
once the requirements and specification are created by the 
development team, and agreed on by the sponsor, the 
component selection and integration is then refined through 
an series of developmental cycles rather than a single 
event. BioRAPIDS was instantiated through a series of rapid 
prototyping, testing, feedback and redesign events. Within 
this cycle, prototyping was begun at the earliest possible 
stage whether with all or just some of the components. By 
doing so, problems were discovered earlier rather than 
waiting for the entire system to be ready prior to prototype 
testing. Since the three main components of BioRAPIDS were 

being procured, developed, and integrated in a parallel 
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manner the iterative process was implemented in various 
combinations of system, from independent components to a 
fully integrated system. Each change to a component could 
be tested with an older version of the others prior to 
integrating and testing the entire system. 

This allowed maximum use of the period encompassing 
Phases B through D. As opposed to the use of a one 
dimensional approach, the prototype produced from using a 
spiral/iterative approach is a much more mature system with 
greater testing and development behind it. 

Due to the dispersed nature of the BioRAPIDS 
development team, much of the colaboration and integration 
was done independently at remote location with regular team 
metings to synchronize the overall efforts. The BioRAPIDS 
schedule listed in Figure 5 shows how the development was 
broken up into three phases and outlines the required 
progress of each. Major testing events were scheduled 
within each phase; at the larger testing events all 
available components were brought together and integrated 
system testing was conducted, with the results fed back for 
system adjustments prior to the next itireation. Phase I 
was was used to lay down the foundation of the system, 
focusing on the creation of component specs, CONOPS, 
software requirements, and testing plans. Phases II and III 
are more operationally focused and are aimed at field 
testing devices and refining integration points and system 
performance. 
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Project Phase 1: 

• Develop a general concept of operatons 

• Develop a detailed transmitter specification 

o Test and evaluate biometnc sensitivity for heartbeat monitor 
o Develop standard information codes 
o Develop measures for device perfomiance 

• Develop detailed network specification 

o Node density scenarios for micro and macro tracking 
o Backhaul connectivity, repeater chains 
o Network management—self and external 

• Develop detailed sottware specification 

o Biometnc sensor integration in RAPIDS 
o Monitonng and alanning based on user tracking 
o User interlace 

• Develop Test and Evaluatton (T&E) plan 

• COASTS FEXI Operation - Camp Roberts. CA 

o Validate user interface in peer review mode with simulated biosensor message 
o Feasibility and completeness review of Gerteral CONORS 
o Feasibility and completeness review of Test and Evaluation Plan 
o Fit test of heartbeat sensor 
o Functionally representative hardware 

o Feasibility and completeness review of BioRAPIDS Network Interface Specification 

o System components (some of them prototypes) will be integrated together to understand the system requirements 
Project Phase 2: 

• Construct engineenng prototypies for field devices 

• Construct prototypes lor repeaters/backhaul 

• Fine-tune Test and Evaluation (T&E) plan 

• COASTS FEX II Operation- Camp Roberts. CA 

o Begin CONORS testing 
o Begin system Test and Evaluation 
o End to end message test on network 
o Functionally representative hardware 

• COASTS FEX III Operation- Camp Roberts. CA 

o Partial CONORS testing 
o Continue system Test and Evaluation 
o End to end message transmission on network 
o First revision of system hardware 
o Test hardware configuration to be taken to Thailand 

• COASTS FEX IV Operation - Thailand 

o During this phase at least one biosensor will be test integrated with the BioRAPIDS system 
o Partial CONORS testing 
o Continue system Test and Evaluation 
o End to end message transmission on network 

o Scenario Testing- use from 4 to 10 transmitter nodes over the course of the various field expenments 
o Finalize System Configuration 

Project Phase 3: 

• Field Test 1. COASTS FEX V Operation - Thailand 

o Initial Field Test with (resign iteration "O' hardware 

o Dunng this phase at least two heart monitor devices will be tested as integrated with the BioRAPIDS system We will use at 
least 10-25 nodes in realistic operaDonal scenarios 
o A preliminary CONORS will be developied and used for the test plan 
o S^tem Test and Evaluation 
■ Design iteratlm 1 

• Field Test 2. COASTS FEX Ofieration - Camp Roberts. CA 

o Field Test with Design Iteration ‘f hardware 

o Dunng this phase at least three device heart monitor devices will be tested integrated with the BioFtAPIDS system 
o CONORS will be refined 
o System Test and Evaluation 

• Design iteration 2 

• Field Test 3. COASTS FEX Operation - Camp Roberts. CA 

o Field Test with Design iteration ■2' hardware 
o Full CONORS testing 
o System Test and Evaluation 

o This is the final field lest during which the devices will subjected to the most rigorous filed conditions and extreme 
environments In which the device will be tested 

• Repkxt and Recommendations 


Figure 5. 


BioRAPIDS Development Schedule 


Between the major scheduled testing 
scale testing and debugging events of 


events, smaller 
opportunity were 
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continuously ongoing. Each of the development nodes 
conducted independent testing as feedback was implemented 
from previous testing results; and when available, multiple 
integrated components were tested by NFS student efforts at 
U.S. Coast Guard Station in Monterey, CA and Thailand based 
events. 

D. DEVELOPING SUBASSEMBLIES AND COMPONENTS 

The following chapter explores the actual technical 
specifics of developing BioRAPIDS. The required 
documentation will be used to define and bound the system as 
a standalone system and also define how it will fit in the 
RAPIDS System of Systems. It also provides more detail on 
the specific components, integrations, and functions that 
comprise BioRAPIDS. 

Chapter III shows the different components and 
subassemblies within a functional architecutres using IDEFO 
modeling language, depicts the internal signal flows 
throughout the system, and summarizes the form and function 
with an operational architecture. Accompanying the models 
and schematics are written explanations of them, as well as 
a description of the physical components chosen to meet the 
specific system requirements. 
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III. SYSTEM DEVELOPMENT 


This chapter discusses the process of developing the 
integration of the BioRAPIDS system from individual 
components, to subassemblies, and into a fully integrated 
system. Products of this chapter are the various systems 
engineering deliverables, which depict the systems 
engineering process (as discussed in Chapter II); from this, 
more details are shown regarding the interactions between 
individual components, and between user and system based on 
the system functions and integration points. Integration 
Definition for Function Modeling (IDEFO) will be used to 
observe the activities of the BioRAPIDS system and 
graphically represent them. By using the IDEFO model, it is 
easy to traverse between functional levels and verify that 
all functional requirements are met and resources are 
utilized efficiently. Along with the IDEFO models, signal 
flow and interface diagrams are discussed, and an 
operational architecture summarizes form and function in a 
side-by-side analysis and traceability. 

A. SYSTEM DEVELOPMENT OVERVIEW 

One of the main goals in developing BioRAPIDS is to 
ensure that the principles of the systems engineering 
process are actively utilized to either directly conduct the 
development phases or analyze the actual actions taken, and 
examine how the deviation impacts the overall process. For 
example, an Originating Requirements Document (ORD) is 
normally set out by a customer and a separate entity works 
to develop a system that will meet these requirements. 
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However, in the case of BioRAPIDS, the development team was 
tasked to develop the specific requirements, and then find 
the appropriate solutions. Although not being the 
traditional way of performing these functions, all 
requirements and proposed solutions were vetted through the 
customer, so the end goal was still the same. 

The primary system development objective was to meet 
one of the most fundamental aims of the Systems Engineering 
process: defining customer needs and required functionality 
early in the development cycle, documenting requirements, 
detailed system design, then proceeding with design 
synthesis and system validation while considering the 
complete problem in order to enable the realization of a 
successful system. 

The identification of actual system components was 
addressed through different paths. As outlined in the 
Systems Engineering approach (Chapter II), the requirements 
are first determined and agreed on by both sponsor and 
development team. Then, the individual subassemblies are 
identified by their function and the individual parts are 
designed to meet the requirements of the higher-level 
assembly, to the needed component specifications. Since the 
development process implemented during this thesis was 
predicated on the use of COTS/GOTS technology for all 
components/assemblies, specific equipment performance 
factors were for the most part not internally controlled. 
Using COTS/GOTS technology as the backbone for the system 
development allowed for a faster development timeline and a 
lower development cost. However, this benefit came at the 
cost of not always being able to select specific performance 
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factors or limiting the components to only the needed 
functions. The process itself was a "skunk works" approach, 
rather than a more formal system development approach (of 
control of performance of the smallest components), which 
had both advantages and disadvantages. The inherent 
flexibility of this approach made system modifications much 
easier to implement, while the lower level of formality 
reduced some of the useful structure to the project. The 
heaviest weighted factor in designing the system was cost 
closely followed by time of availability. While performance 
and capability were always a consideration in order to meet 
the sponsor needs, cost and timeline were the limiting 
factors for the level of robustness and refinement that was 
reached. As additional funding was available and/or a more 
capable component were found and implemented, the 
suitability determination for that component was made by 
tracing its functionality through the IDEFO models (shown 
later in this chapter) . Through the use of the spiral 
development model (shown in Chapter II), this process of 
upgrading and modifying system components is constantly 
ongoing and the final components used vary greatly from 
those first identified. 

The main intent of assembling the BioRAPIDS system with 
COTS/GOTS technology was to minimize cost and time. As 
already discussed, the main advantage of using existing 
technology is the lack of research and development (R&D) 
cost and time associated with developing and testing new 
components. A second benefit from COTS/GOTS components is 
that they have already been tested and validated for their 
core function. Therefore, when utilizing a component, the 

testing is more focused on the integration and operational 

39 



validation without needing extensive base functionality 
testing. A third advantage, specifically in using GOTS 
technology, is that when using a system that is already in 
the inventory it minimizes the amount of contracting time, 
training required, and documentation for that system. In an 
operational sense, this reduces the burden on the "soldier" 
by not introducing an additional load; for example, if a 
personal tactical radio, which is already part of a 
soldier's equipment is integrated into the system instead of 
a separate BioRAPIDS one, it eliminates the need for 
additional equipment when fielding BioRAPIDS. In this case, 
BioRAPIDS is integrated into existing infrastructure rather 
than becoming a new stove piped system. In the long run, 
this reduces the costs and timelines associated with 
acquiring and fielding a new system, and allows the system 
to more efficiently complement existing capabilities. 

B. SYSTEM REQUIREMENTS AND SPECIFICATIONS 

The basic process for developing a system is to 
understand the requirements first (based on the needs 
statement, operational concept and scenarios). A clear 
understanding of what is required of the system is crucial 
to ensure that the expectations match reality. In the 
BioRAPIDS system development, there are two main areas that 
were considered when determining all the respective 
requirements for a new system: the technical requirements 
and the operational requirements (as they may put an 
additional demand on system functionality). 
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1 . 


Technical Requirements 


The first step is to understand what the system needs 
to do. This mainly occurs in the X and A phases of the 
Systems Engineering process (as discussed in Chapter II). A 
systematic analysis of the requirements can be done by 
starting with a high-level view (preliminary system design) 
and then working down into the more technical specifications 
of individual components. 

The X phase gives the need, which in this project is to 
be able to monitor a "soldier's" vital signs and location. 
Then network the information back to a command center where 
the real-time condition of the field personnel can be 
monitored, and alerts created by hazardous conditions based 
on predetermined trigger points. The level of monitoring is 
scalable from a small number of individuals conducting a 
clandestine operation, to an entire battlefield of soldiers 
depending on how a commander wishes to implement it. From 
here, the operational concept and scenarios were developed 
to those presented in Chapter I. In further developing the 
system a analysis was conducted of all layers of 
functionality, begining with an ESD to understand how this 
capability will fit into the broader picture of the RAPIDS 
sensor fusion/management architecture. This first view 
bound the system development and design by defining 
BioRAPIDS function within a larger architecture. Figure 6 
shows the external systems diagram of BioRAPIDS as a 
component of the RAPIDS system of systems, a broader 
networked sensor fusion/management system. Although in a 
true sense, BioRAPIDS is essentially another sensor in the 
RAPIDS system and could be included within that block, it 
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was broken out here simply to highlight its place within in 
the broader architecture of the RAPIDS system of systems. 


Connectivity and Network Program System Sensor 

Bandwidth Settings Settings Capabilities Capabilities 



Figure 6 


BioRAPIDS External Systems Diagram 


Through this graphical model, one can see that the main 
function of BioRAPIDS is to provide processed Heart Rate 
(HR) and GPS data to the overall RAPIDS network. The 
BioRAPIDS data is then incorporated into the RAPIDS system, 
which not only displays the BioRAPIDS exclusive information, 
but also fuses it with other sensor data to formulate a 
clear unambiguous operational picture. For example, when 
the GPS data provided by BioRAPIDS is compared to, perhaps a 
radar hit or a ground sensor hit, all inputs are compared 
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and fused so that the resulting display information will 
show one coherent target, vice three different entities 
based on each sensor's input. 

Based on this high-level view of the RAPIDS system's 
operational interactions, the process of determining the 
functional requirements for BioRAPIDS began with the 
development of a functional hierarchy, found in section D of 
this chapter. As each system layer of functionality is 
explored, the different requirements and interfaces were 
developed to meet each layer's functional requirement 
therefore creating a physical architecture hierarchy to 
ensure that each required function or interface is addressed 
by a specific physical component. 

BioRAPIDS' function based on the external systems 
diagram, is composed of three technical challenges. First, 
the system must incorporate sensors capable of monitoring 
and measuring a person's heart rate and obtaining GPS 
location information. Next, the system must be capable of 
transmitting the gathered the gathered sensor data. Lastly, 
the system must be able to process the raw data, display it, 
and integrate it with the RAPIDS management system; see 
Figure 7 for a system overview of the BioRAPIDS System. 



Figure 7. BioRAPIDS System Overview 
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The system overview is the high-level depiction 
(preliminary system design) of the anticipated system with 
some preliminary interface description. This was a starting 
point for picturing how the future system would be 
constructed. Adding the information from the external 
systems diagram, the operational requirements listed in 
Chapter I, and using the IDEFO functional architecture 
decomposition models from section C of this chapter, a more 
detailed vision of the required components and integration 
points was developed and studied. A physical architecture 
was developed from which COTS/GOTS components were then 
selected and modified to meet the technical requirements of 
BioRAPIDS. Finally, an operational architecture was created 
to ensure that traceability was maintained between required 
functions and system components. 

2. Operational Requirements 

Similar to the technical requirements, operational 
requirements posed their own challenges to overcome. While 
the physical architecture shown in section D of this chapter 
provides a more technical solution to the functional 
requirements, the CONOPS scenarios outlined in Chapter I, 
identify additional component attributes required. The 
final is clearly affected, as the choice needs to meet both 
technical and operational requirements. In a typical 
development scenario, the component and subassemblies are 
designed almost entirely with technical specifications in 
mind. As the system achieves a higher level of maturity and 
field-testing commences, CONOPS scenarios are then developed 
to incorporate operational requirements, such as 


weatherproofing or miniaturizing. In the case of BioRAPIDS 
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the need for maximizing the component selection process was 
emphasized earlier in the development process. In examining 
the CONOPS scenarios up front, component selection 
incorporated not only the technical factors but also the 
physical characteristics of the equipment. 

3. Additional Requirement Considerations 

Keeping the timeline in mind, there are other 
considerations that were taken into account during the 
component selection. Similar to using the CONOPS scenarios 
as an added input to the system requirements, the BioRAPIDS 
test and evaluation (T&E) plan was factored into the 
process. Although the testing and evaluation does not occur 
until further into the development timeline, it was 
important to know what the end goal of performance was when 
selecting the individual components to minimize the required 
adjustments during the testing phase. In using COTS/GOTS 
gear for system components, the final performance 
requirements are important to understand upfront, since the 
ability to alter a COTS/GOTS design significantly is 
limited. Therefore, if a deficiency is found during the 
testing phase, it may require identifying and acquiring a 
whole new component in order to rectify the problem, 
therefore greatly impacting the time and money needed. 

The following items are the broad performance measures 
that will later be used during the T&E phase and were 
considered during component selection.® 


® Performance measures taken from BioRAPIDS Test and Evaluation Plan 
(Test Plan, Oct 2008). 
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Feasibility 


a. 

Feasibility is not generally recognized as a 
performance measure, but it is in a rudimentary sense. The 
test effort will be devoted to the feasibility of the 

BIORAPIDS product in two categories. 

(1) Technical Feasibility. 

• Is the BIORAPIDS Network interface adequate to 

extract all the relevant information? 

• Is the BIORAPIDS wireless transmission and 

bandwidth adequate for passing relevant messages? 

• Is the BIORAPIDS device able to measure and 

monitor the primary sensor variables such as Heart 
Rate (HR) 

• Also—are future BIORAPIDS devices able to measure 

other variables such as Breathing Rate (BR), Skin 
Temperature (T), Posture (P), Activity (A) -These 
measurements are not required for the BIORAPIDS 

project, but as many sensors do provide these 

readings, they may be evaluated alongside the 
heartbeat readings for possible inclusion during 
this project or at a later date. 

(2) Deployment Feasibility. 

• Can the BIORAPIDS device be worn with minimal 
discomfort to the user? 

• Is the weight, power requirements of the device 

reasonable? 

• How easy it is to replace faulty components or 

devices ? 

ib. Ease of Use 


Assuming that the end user has minimal computer 


knowledge, then 

ease 

of use must 

be viwed 

from the 

end 

user's point 

of 

view. 

GUI testing 

verifies 

operability 

of 

the system. 

as 

well 

as the aesthetic designs impact 

on 
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usability (font color, text format, labels, background, 
foreground, etc) . The ease of use of the product will be 
tested in view of the following questions: 

• Is each GUI easy to comprehend and monitor? 

• Is the "Personal Icon" easy to read and interpret? 

• Does the "Personal Icon" satisfy the DOD 
standards ? 

• Do the various heart monitor deices use the same 
GUI interface as per the BIORAPIDS Network 
Interface Standard or does it vary? If yes why? 

• Is it easy to respond to "audible" alarms 

depicting violation of the standard biometric 
sensor variables? 

• We will judge the usability of each GUI screen 

based on the following criteria: 

• Time to learn 

• Speed of performance 

• Rate of errors by users 

• Retention over time 

• Subjective satisfaction 

c. Portability 

• Is the device portable? 

• Is it easily configurable? 

• Is it portable across different applications and 

different terrains? 

d. Reliability 

• Does the device perform reliably? 

• What is the reliability of the hardware 

components ? 

• How often does the software crash and under what 
circumstances ? 
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e. Robustness'^ 

• Is BIORAPIDS ruggedized? 

• What extent of temperatures can it operate? 

• What is the water/moisture tolerance level for the 
device? 

• Can it withstand shock to an appreciable extent? 

f. Accuracy 

• How well does the device actually read the 
heartbeat ? 

g. Biosensor Performance Requirements 

• What are the thresholds for each measure? 

• Need to have the ability to do Averaging of 
heartbeat overtime 

• Error checking of sensors. 

C. FUNCTIONAL ARCHITECTURE 

Once the system requirements were identified, the next 
systems engineering development step was to conduct a more 
in depth analysis of the specific functions and interfaces 
of the components and subassemblies encompassed by the 
BioRAPIDS system. This portion of the development process 
bridges the gap between Phases A and B of the development 
cycle and began the transformation of the idea (needs 
statement) into a viable product. The mapping of the system 
is divided into functional and physical analysis. 
Typically, the functional architecture is modeled and then 

MIL-STD-810G 31 October 2008, was used as a guideline to understand 
the requirements to meet the specified certifications concerning 
environmental protection. The final prototype that will be produced at 
the end of this project is not intended to meet military standards for 
environmental protection. 
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the physical one follows to match the functional requisites 
with a particular physical component. In developing the 
architectures for BioRAPIDS, there is a slight "chicken and 
egg conundrum." On the one hand, BioRAPIDS is an extension 
of the existing RAPIDS C2 sensor management system, and 
therefore, some of the physical components had already been 
identified. The transceiver, which was already in use to 
track other assets, was determined to be the transceiver of 
choice for BioRAPIDS since it was readily available and 
incurred almost no additional cost to procure. Conversely, 
the selection of the sensor is based on cost and 
availability, and therefore, the exact performance of a 
particular component could not be controlled 100% by the 
development team. In the case of the transceiver, the 
required functions were determined and modifications were 
made to an existing RAPIDS component, to meet BioRAPIDS 
specific requirements. To keep with convention and to 
continue with the theme of functional requirements from the 
previous two sections, the functional architecture will be 
discussed first. In creating the functional architecture, 
the needed functions were taken from the requirements 
document and displayed in a functional architecture 
hierarchy, describing the particular functions. It also 
organizes them in a functional architecture hierarchy 
decomposition of levels that show basic interactions between 
functions using IDEFO modeling. Figure 8 is the high-level 
functional architecture hierarchy from which the following 
IDEFO functional architecture decomposition system models 
are based. 
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Figure 8. 


Functional Architecture Hierarchy 


The functional architecture is organized in a way to 
support the assumption that three capabilities were required 
to meet the overall need. The three main functions depicted 
on the architecture, in Figure 8, are the ability to collect 
and format bio-status information; the ability to transmit 
and receive bio-status and location data; and, to provide 
processed data management and display. 
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Following the architecture hierarchy, BioRAPIDS 
functionality is modeled using IDEFO models. The first 
model shown in Figure 9 is the high-level functional 
architecture decomposition model in the IDEFO format. The 
function performed is inside the block; the system name 
listed at the bottom (with arrows going into the bottom of 
the box); the inputs come in from the left; the constraints 
come from above; and, the outputs are represented coming 
from the central block and proceeding to the right. 



Figure 9. BioRAPIDS functional architecture 

decomposition AO Model 


Beginning with Figure 10, the models are separated by 
the specific subassemblies and components. 
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Figure 10. Sensor Subassembly Functional Architecture 

Decompositions (Al) and (A1.3). A1(above) is the 
overall sensor subassembly function, and Al.3(below) is 
functional architecture decomposition of the data 
processor component 
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Figure 11. Transceiver Subassembly functional 

architecture decomposition. Functional architecture 
decomposition A2(above) is the overall transceiver 
subassembly, and functional architecture decomposition 
A2.1 (below) the radio component decomposition 
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Figure 12. Data Management Subassembly functional 

architecture decomposition (A3 previous page top), 

(A3.1 previous page bottom), (A3.2 above). Functional 
architecture decomposition A3 is the overall data 
management subassembly, and A3.1/A3.2 are the hardware 
and software models, respectively 

The separation of the overall BioRAPIDS system into 
three main functions, as depicted in the functional 
architecture decomposition of Figure 8, is carried through 
in the IDEFO models. Using this functional architecture 
development approach is what allows the traceability of a 
component's functions and placement within the overall 
system. 

The following section of this chapter contains the 
physical architecture hierarchy and signal flow diagrams, 
which were, derived from the functional architecture 
hierarchy and IDEFO models. Once the physical components 
were identified and mapped, a complete traceability of form 
and function was done through the operational architecture; 
and, alternate COTS/GOTS components can be examined in its 
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proposed location within the overall context. As new 
COTS/GOTS components became available, this model testing 
process was done to determine the new components 
suitability. 

D. PHYSICAL ARCHITECTURE, SYSTEM SIGNAL FLOW, INTERFACE 

ARCHITECTURE, AND OPERATIONAL ARCHITECTURE 

This section discusses the physical architecture and 
incorporates the COTS/GOTS components selected. COTS/GOTS 
component selection and organization is discussed based on 
the required functions depicted in the previous section of 
this chapter. The format continues the division of the 
three main sub functions of Figure 8, into physical 
architecture subassemblies and then follows to display the 
individual components that make up each subassembly. 
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Figure 13. BioRAPIDS Physical Architecture Hierarchy 

Mirroring the functional architecture allows the 
functions of the physical components chosen(Figure 13) to be 
verified and compared to the functional architecture 
(creating an operational architecture) which allows 
traceability and efficiency of resources. 


57 



















































































































with BioRAPIDS component selection being at the mercy 
of COTS/GOTS components, the development team does not have 
complete control of all the performance factors of a 
particular component. With a compressed timeline in which 
to plan, design, integrate, test and deliver the system, 
choices had to contend with availability and cost, which 
were not always in line with the most cost-effective or 
efficient choice, and the trade-off decisions were made. 

An example of this occurs with the selection of the 
sensor data processor. The initial choice of an OQO ultra 
portable computer more than meets the requirements for a 
component to take the raw sensor data and convert the signal 
into the proper transmission message format. The capability 
possessed by the OQO far exceeds the requirements of the 
BioRAPIDS system. However, by using the OQO, no additional 
cost was incurred since it was already available to one of 
the development team members; it also allowed the 
demonstration of the RAPIDS common operating picture at a 
mobile node, which was not a BioRAPIDS requirement but does 
add potential capabilities. A simple microprocessor is 
sufficient to perform the operations required by BioRAPIDS, 
and in a long term production of the system, is the more 
economical approach. However in creating a proof of concept 
device it was more economical to use components on hand, 
even if they exceeded requirements rather than designing and 
manufacturing individual components which would only meet 
the requirements. Great effort was made to minimize 
unneeded capabilities, and through extensive research of 
available components, it was done to the greatest extent 
practical. 
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Following the physical architecture is the description 
of the signal flow through each of the components and 
subassemblies. Since the selected components were not 
designed to be implemented in the BioRAPIDS context, but 
rather as COTS/GOTS components with their own application, 
interfaces were designed with a bottom up approach to 
integrate them into a cohesive system. 


1. Sensor Subassembly 


The sensor subassembly (Figure 10—Al) was one of the 
more crucial components since it addressed one of the main 
functions of the BioRAPIDS system, to measure heartbeats. 
This component was not an alteration to an existing 
capability of the RAPIDS sensor management system, but an 
entirely new capability. Initially, the thought was to 
obtain a sensor that would obtain a number of bio-state 
parameters, in order to have a complete picture of the 
user's health status. The different choices that were 
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Figure 14. Sensor Subassembly Internal Flow Diagram 
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analyzed (Requirements, Sep 2008) as being viable sensors 
vary greatly in performance, availability, ruggedness, and 
cost. The ultimate sensor selected was almost exclusively a 
function of cost, as the budget allotted for this part of 
the project was extremely limited. Performance and 
ruggedness were the next discriminates, but both of those 
parameters were closely correlated to cost, and any 
significant improvement on the sensor chosen required an 
exponential rise in cost. Ultimately, a team decision was 
made to remain within the original BioRAPIDS requirement of 
only measuring heart rate, rather than attempting to obtain 
a multi-parameter sensor since it would greatly exceed cost 
constraints. 

The signal flow through the system depicted in Figure 7 
is further explored in this section. The sensor subassembly 
depicted in Figure 14 follows the standard convention of 
inputs coming from the right and proceeding to the left. 
The boxes encompass the actual components and the lines 
indicate the flow. On the flow lines, the type of 
information being carried is listed above the line and the 
carrier is listed below it. The heartbeat is measured by 
the sensor, which is placed on the user's chest; the raw 
heart beat count is transmitted wirelessly to the processor 
component; and, the processor then outputs a formatted heart 
rate message via RS232 cable to the transmitter subassembly. 
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Figure 15. Numetrex Sensor with Polar transmitter 


Physically, the sensor was composed of components from 
the fitness industry. The sensor selected is a cardio shirt 
with woven fibers, manufactured by Numetrex, Inc. and came 
about as a result of initial testing feedback on a different 
sensor. When the initial search for sensors was conducted, 
the Numetrex shirt was not discovered as one of the initial 
options. It was only after the initial BioRAPIDS 

configuration testing with an Acumen TZ Max-100 showed the 
sensor to be inadequate for the system requirements, that 
the Numetrex shirt was found through further research. The 
NuMetrex line of heart rate monitoring athletic apparel uses 
innovative "smart fabric" technology that incorporates 
special sensing fibers directly into the fabric of its 
garments. Replacing the hard plastic chest straps that rub 
and chafe against the skin, Numetrex offers a comfortable 
alternative with form-fitting shirts and sports bras that 
sense your pulse and transmit it to a compatible wristwatch 
or exercise machine. The textile electrodes that are 
knitted into the fabric stretch and move as you do, 
maintaining contact with your skin and sensing your heart's 

electrical pulse. A tiny transmitter is snapped into a 
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small pocket in the front of the garment, where it 
instantaneously radios your heart rate.^ 

To receive the transmitted heart rate, the use of a 
Polar OEM wireless receiver was coupled to an I/O USB 
counter device, which along with a rugged computer served as 
the processor component. The following sections cover the 
individual components that were introduced, in more 
technical detail. 

a. Numetrex Cardio Shirt 

Special sensors are knit into the fabric of 
seamless athletic apparel. The textile sensors maintain 
contact with the body, sensing the wearer's heart rate and 
relaying it to a tiny transmitter. 

The transmitter is snapped into a pocket in the 
front of the garment. It captures the heart beat data and 
transmits it to the receiver component. 

b. Processor Unit 

The Polar OEM receiver is collocated with a USB 
event counter module (ADVANTECH, Co.)^ to take the raw heart 
beat count, process it into a heart rate, and then format it 
into the required BioRAPIDS message format. The output is 
then buffered for transmission via an RS232 cable into the 
transmitter input. 


° Numetrex cardio shirt description provided from manufacturer Web 
site: http://www.numetrex.com/about/technical-story. 

® Counter specifications were provided by manufacturer. 
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Introduction 


Features 

■ Compatible with USB 1.1/2.0 

■ Portable 

■ Bus-powered 

■ 48/24TTL digital I/O lines 

■ Emulates mode 0 of 8255 PPI 

■ Buttered circuits for higher driving capacity than the 8255 
• Interrupt handling 

■ Timer/Counter interrupt capability 

■ Suppods both dry and wet contact 

■ 50-pin Opto-22 compatible box header 

■ Suitable for DIN-rail mounting 

■ One lockable USB cable for secure connection included 


The USB-4700 series consists of true Plug & Play data acquisition devices. No more opening up your computer chassis to install boards-just plug in the module, then get the data 
It's easy and efficient. USB-4751/4751L is a 48/24-bit digital I/O module for the USB bus. Its 48/24 bits are divided into six/three 8-bit I/O pods and users can configure each pod as 
input or output via software. USB-4751/USB-4751L also provides one event counter and three 16-bit timers, which can be cascaded to become a 32-bit timet. 


Specifuations 


Digital Input 

■ Channels 48/24 (shared with output) 

• Compatibility 5 V/TTL 

■ Input Voltage Logic 0:0.8 V max. 

Logic 1:2 V min. 


Digital Output 

■ Channels 

■ Compatibility 

■ Output Voltage 

• Output Capability 


48/24 (shared with input) 

5V/nL 

Logic 0:0.5 V max. 

Logic 1:3.8 V min. 

Sink: 12 mA@ 0.5 V 

Source: 12 mA r® 3.8 V for single Channels 

5 mA @ 3.8 V for all Channels in High status 


Counter/Timer 

■ Channels 2 

• Resolution 32-bit 

■ Max. Input Frequency 8 MHz 


General 


■ Bus Type USB 1. 1/2.0 

■ I/O Connectors 50-pin IDC male connectors, pin assignments are fully 

compatible with Opto-22 I/O module racks 

• Dimensions (Lx W X H) 132 x 80 x 32mm 

■ Power Consumption Typical: 200 mA ® 5 V 

Max.:500mA@5V 

• Operating Temperature 0-60° C (32-140° F) (refer to lEC 68-2-1,2) 

■ Storage Temperature -20 - 70° C (-4-158° F) 

• Storage Humidity 5-95% RH, non-condensing (refer to lEC 68-2-3) 


Ordering Information 


■ USB-4751 

■ USB-4751 L 
• 1960004544 

■ 1960005788 


48-ch Digital I/O USB Module 
24-ch DigiUI VO USB Module 
Wallmount Bracket 
VESA Mount Bracket 


Figure 16. 


BioRAPIDS Sensor Data 
Specifications 


Processor 


Transceiver Subassembly 


The transceiver chosen was the Wolfpack II UHF personal 
locator radio. The model used was a modified version of an 
existing production model from Electricore, Inc. The 
WOLFPACK II GPS transponder is a rugged high-speed UHF data 
modem with a built-in 12-channel GPS receiver. It has 0.5 
to 5 watts of RF power output, and operates as both a GPS 
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transponder for tracking, and a radio modem for sending and 
receiving data (WOLFPACK Manual, Jan 2009). 



Figure 17. Wolfpack II Transceiver 


The transceiver itself is a self-contained unit and as 
testing occurred, modifications were made to the original 
device. Prior to doing any testing, various modifications 
were required in order to meet certain CONOPS requirements 
and the overall transceiver specifications are listed in the 
Transmitter Interface Specifications document (Transmitter 
Interface, Oct 2008) . The were relatively small in a 
technical sense, but had a larger impact in an operational 
sense. Among the initial changes, was changing toggle 
switches to push buttons preventing inadvertent actuation; 
removal of function lights for stealth; change the longer 
antenna to a shorter omni-directional one; and increased 
battery life. 

The signal flow through the transceiver unit is shown 

in Figure 18, and has three main inputs to it. The signal 
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flow is fairly simple through this subassembly; the 
formatted heart rate message enters through the data port, 
is combined with the GPS data and is then transmitted out to 
the data management subassembly. 



Figure 18. Transceiver Internal Signal Flow 


3. Data Management Subassembly 

The data management subassembly is composed of three 
main components: the hardware, the software, and the network 
interface. The hardware is simply the normal parts that 
make up a computer system, keyboards, display monitor, I/O 
devices, mice, etc. The network interface varies as it 
depends on the configuration of the system: the organic set¬ 
up is to use two transceivers to connect to the network, one 
located with the user and the other at the command node to 
receive the transmitted data. Other configurations set-ups 
include 802.11 and satellite links, and essentially any 
other form of communication that can link computers 
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together- all mission dependent. The network interface is 
not a static component, but a dynamic one that can be easily 
adapted to the required communication limitations of real 
operational environments. The software specifics of the 
network interface are described in detail in the software 
and network interface documents (Software Interface, Oct 
2008), (Network Interface, Oct 2008). This delineates 
message formats, transmission cycles, and overall 
integration between the BioRAPIDS sensor, and the data 
fusion/management network. 

The software component of the processing and display 
portion of this subassembly was developed by A3IT Solutions 
and is specifically tailored for the BioRAPIDS application. 
With this new application, the software that controls the 
processing and display have been developed using a bottom-up 
approach. 

An initial user's manual (BioRAPIDS Guide, Mar 2009) 
sheds some light into the software functionality and 
capability of the display and alarm functions of BioRAPIDS. 
Figure 19 below shows the signal flow through the 
subassembly. The diagram does not specifically identify 
which component is exclusively software, as software is 
embedded into almost all the components. The biggest impact 
of the software is seen at the configuration and alarm 
options sections as well as the CPU. All the functions 
being carried out in these components were internally 
developed exclusively for the BioRAPIDS application. 
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Figure 19. BioRAPIDS Data Management Internal Flow 

Diagram 

E. FUNCTIONAL/PHYSICAL TRACEABILITY THROUGH OPERATIONAL 
ARCHITECTURE 

An ever-important function of following a systems 
engineering development approach is the ability to trace the 
specific physical component to a desired function. By being 
able to equate a function with a physical component, 
accountability of particular functions is readily 
accomplished, and efficiency is assured by quickly 
identifying any superfluous components in the system. Table 
1 provides a matrix to trace each component to its 
corresponding function based on the functional and physical 
architecture hierarchies. 
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BioRAPIDS 

Hierarchy 

Level 

Functional Requirements 

Physical Component 


Monitor and Report 
Processed personnel Health 
Status and Location 

BioRAPIDS System 

AO 



Collect and Format Bio- 

Status Information 

Sensor 

A. 1 

Encase and protect 
sensor internal circuitry 

Sensor Housing 

A. 1.1 

Measure Heart Beat 

Sensor Contacts 

A. 1.2 

Process raw heart beat 

data 

Data Processor 

A. 1.3 

Convert raw data into 
formatted system message 

CPU 

A.1.3.1 

Buffer formatted system 
messages for transmission 

Memory 

A.1.3.2 

Supply power to sensor 
components 

Power Supply 

A. 1.4 

Provide path for data 
export 

Output Interface 

A. 1.5 


Transmit and Receive Bio- 

Status and Location 
Information 

Transceiver 

A. 2 

Provide RF Communications 

Radio 

A.2.1 

Encase and protect 
tranceiver circuitry 

Housing 

A.2.1 . 1 

Set up/Operate Radio 
Functionality 

Cont rols 

A.2.1.2 

Supply power to Radio 
Components 

Battery 

A.2.1.3 

Conduct optimized over the 
air transmissions 

Transmitter/Receiver 

A.2.1. 4 

Obtain Global Positioning 
System data 

GPS Assembly 

A.2.2 

Provide interface 

connection for sensor 

Data Ports 

A.2.3 


Table 1. 


Functional/Physical 
(Operational 


Traceability 

Architecture) 


Matrix 
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F. SYSTEM CONFIGURATION 

The following chapter discusses the testing conducted 
and the iterative spiral progression of the system. The 
chapter begins by recounting the configuration selected 
prior to the initial field test; and will discuss upgraded 
configurations based on the testing feedback along with the 
specific integration points. The results from each test 
will be evaluated and recommendations fed back to the 
process prior to the next round of testing, in accordance 
with the spiral method used. 
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IV. SYSTEM TESTING AND FEEDBACK 


Following the painstaking process of identifying all 
the components and the required functions detailed in 
Chapters II and III, the next step of the BioRAPIDS 
development is the component integration and testing. In 
regards to the project timeline, this encompasses the latter 
part of phase C but mainly addresses phase D. 

Testing of the system consists of a series of events in 
which individual components are tested to validate their 
functionality. As the individual components are validated, 
testing of different component configurations, at evolving 
stages of integration, is conducted to test the different 
interfaces as well as combined component behavior. The 
final event in this thesis is a test of a fully integrated 
proof-of-concept system. 

The rest of this chapter chronicles the evolutionary 
spiral model of testing and modifying the system 
configuration or component selection. Based on the results 
from each round of testing, adjustments are made to enhance 
performance. Testing is continuously ongoing as new 
developments arise, with some pre-determined events being of 
larger scale and more structure in their scope. Smaller 
scale, impromptu testing events were conducted by different 
members of the development team as they worked on a 
particular subassembly. It is essential that small scale 
testing be conducted prior to integrating multiple 
components so that integrated testing can concentrate more 
on interfaces rather than on the individual component 
performance. Of course, there is no certainty that an 
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individual component will always behave in the same manner 
whether tested as a stand alone or as an integrated 
component, but eliminating as many individual bugs resulted 
in better integrated tests. The testing events delineated 
in the program timeline are meant to bring all pieces 
together in order to test the complete system and determine 
the system status and rate of progress based on required 
contract milestones. 

Testing is where rubber meets the road. Theoretical 
and laboratory experimentation of a system's capabilities 
and limitations has a great deal of usefulness; it allows 
the development of the system architecture, interfaces, and 
component requirements in a controlled environment. 
However, to transition a system into the operational realm, 
it is necessary to conduct testing in the field under as 
many expected operating conditions as possible to understand 
the system's capabilities in the face of uncontrollable 
variables. Field testing is the step required to transition 
from what could be to what is. 

At this point, it is useful to recap the project 
timeline in order to understand where system testing fits 
into the overall development process. Figure 20 shows the 
intended system development and testing timeline that was 
originally submitted. Due to circumstances outside the 
BioRAPIDS project, COASTS was shut down prior to FEX III. 
However, the contract milestones were still required to be 
met; and, adjustments were made to the venues utilized for 
testing, as well as adjustments to the specific dates. To 
satisfy the requirements for testing during the FEX V event, 
BioRAPIDS became part of Crimson Viper 2009 Experimentation 
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Series (CV09).^° The difference in testing is essentially 
transparent as it applies to BioRAPIDS, but the change is 
noted to provide an accurate account of events supporting 
this thesis. 

The period of investigation of this thesis covers the 
first two phases of development shown in Figure 20. Of 
these two phases, the first phase is mainly administrative 
in nature, but required evaluation of ideas, initial 
architectures, and early subassembly configurations to 
determine the suitability of chosen components and methods 
of integration. Based on the need to evaluate ideas and 
provide feedback to advance the development process, the 
applicable actions of phase one have been incorporated into 
the testing chapter. While very little empirical data was 
obtained from most of phase one, the description of phase 
one presents a clearer understanding of how the initial 
configuration was determined, and allows for a logical 
organization of the field tests that follow it. At times, 
information provided may seem repetitive to that seen in 
Chapter III: System Development; but, as described earlier, 
the lines between development phases are not always 
exclusive of each other and some events may be applicable in 
multiple phases. 


COASTS transitioned into Crimson Viper. The new program is under 
the guidance of Marine Forces Pacific Experimentation Center (MARFORPAC 
MEC), and aligns experimentation and technologies directly with 
warfighter's needs in support of MARFORPAC and U.S. Forces Pacific 
Command (PACOM) objectives. 
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Project Phase 1: 

• Develop a general concept of operations 

• Develop a detailed transmitter specification 

o Test and evaluate biometric sensitivity for heartbeat monitor 
o Develop standard infomiation codes 
o Develop measures for device performance 

• Develop detailed network specification 

o Node density scenarios for micro and macro tracking 
o Backhaul connectivity, repeater chains 
o Network management—self and external 

• Develop detailed software specification 

o Biometric sensor integration in RAPIDS 
o Monitoring and alanning based on user tracking 
o User interface 

• Develop Test and Evaluation (T&E) plan 

• COASTS FEXI Operation - Camp Roberts. CA 

o Validate user Interface in peer review mode with simulated biosensor message, 
o Feasibility and completeness review of General CONORS 
o Feasibility and completeness review of Test and Evaluation Plan, 
o Fit test of heartbeat sensor, 
o Functionally representative hardware. 

o Feasibility and completeness review of BioRAPIDS Network Interface Specification 

o System components (some of them prototypes) will be integrated together to understand the system requirements. 
Project Phase 2: 

• Construct engineenng prototypes for field devices 

• Construct prototypes for repeaters/backhaul 

• Fine-tune Test and Evaluation (T&E) plan 

• COASTS FEX II Operation- Camp Roberts, CA 

o Begin CONORS testing 
o Begin system Test and Evaluation 
o End to end message test on network 
o Functionally representative hardware. 

• COASTS FEX III Operation- Camp Roberts, CA 

o Partial CONORS testing 
o Continue system Test and Evaluation 
o End to end message transmission on network 
o First revision of system hardware, 
o Test hardware configuration to be taken to Thailand. 

• COASTS FEX IV Operation - Thailand 

o Dunng this phase at least one biosensor will be test integrated with the BioRAPIDS system, 
o Partial CONORS testing 
o Continue system Test and Evaluation 
o End to end message transmission on network 

o Scenario Testing- use from 4 tot 0 transmitter nodes over the course of the various field experiments, 
o Finalize System Configuration 


Figure 20. 


BioRAPIDS Period of 


Thesis 


Investigation 
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A. PRE-FIELD TESTING CONFIGURATION 

1. Sensor Selection 

The three main decision points were performance (number 
of parameters monitored), form factor (weight, size, body 
placement) and cost. The choice between the chosen sensors 
and the optimal one was made very easy in that the sensor of 
choice, the Wealthy Shirt, was prohibitively priced at 
$10,000. The rest of the proposed sensors were adequate for 
providing the required heart monitoring function, but had a 
common undesired form factor; all the monitoring devices 
were of the chest strap variety and were very prone to 
moving from the optimal monitoring spot on the body during 
physical activity. The determination was made to continue 
with further sensor exploration, and in interim, use the TZ 
Max-100 heart rate monitor made by Acumen, INC. as a proof 
of concept testing device. 

2. Transceiver Selection 

The selection process for transceivers was a relatively 
easy one. In this case, the choices were boiled down to 
two. The first was to use any of the GOTS personnel 
communication radios currently in use by operational forces. 
An initial attempt was made to explore this option with an 
AN/PRC-148 Multiband Inter/Intra Team Radio (MBITR). This 
is a software-defined radio that is used to some extent by 
SOF teams. The radio vendor provided a few trial radios, 
but the timeframe allotted to use them was not conducive for 
long range testing, and the actual cost of the system was 
more than prohibitive for the purposes of BioRAPIDS. The 
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final selection was to use the Wolfpack Radios Electricore 
had developed for RAPIDS with technical assistance from 
Raveon Technologies. These required some initial 
modifications that were recognized up front, but their 
availability and proven performance in other RAPIDS 
applications made them a sound choice. 

B. COASTS FEX I EVENT-CAMP ROBERTS, CA (OCTOBER 2008) 

This was the first field-testing event for the 
integrated BioRAPIDS system. The primary goal was to 
determine system feasibility and to review the 
specifications against an operational model. Second was to 


conduct an 

operational 

test 

of 

the 

individual components; 

conducting 

a fit 

test 

on 

the 

HR 

sensor. 

testing radio 

operations, 

reviewing 

the 

GUI 

capability 

and look, and 

finalizing 

CONOPS 

documents 

and 

T&E 

plans. 

The following 


are testing results from FEX I. 

1. Sensor Subassembly 

The sensor used was the TZ-Max 100 Heart Rate monitor 
by Acumen, Inc. While not necessarily the primary sensor of 
choice, the TZIOO was used to test the capability of 
transmitting heart rate monitoring information through the 
RAPIDS network. This is a basic consumer heart rate monitor 
with downloadable heart rate and work out information via a 
USB connection, through a cradle. 
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Figure 21. TZ-MAX 100 Technical Guide 
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Figure 22. TZ Max-100 Components 
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Achievements 


a. 

Fit testing was conducted to verify the sensors 
ability to monitor heart rate correctly. It was found that, 
as expected, the heart rate provided by the sensor was no 
more than one or two beats off from a manual measurement. 

Water resistance was tested on the monitor and it 
was found to continue to measure heart rate accurately up to 
a depth of six feet (maximum depth of the test pool) . The 
trial was conducted on three different days with each day 
being comprised of three independent trials of 30 minutes in 
length. There was no significant difference between each 
test. The monitors output and a manual measurement of heart 
rate were similar regardless of the precense of water. 
Shallow water submerssion did not have an adverse impact on 
sensor performance. 

b. Problems 

Two separate problems were identified as soon as 
testing began. The first was the sensor's inability to 
stream heart rate data continuously. In order to transmit 
heart rate information, it would require user manipulation 
of the sensor. This of course is unacceptable based on both 
technical and CONOPS requirements. Secondly, the team was 
unable to obtain permission to access the sensors SDK in 
order to create the needed interfaces to transmit the data 
in a RAPIDS display format. The TZ Max-100 used a 
proprietary GUI and therefore limited the team's ability to 
modify output information to fit BioRAPIDS requirements. 
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c. Testing Feedback 

A new sensor is needed, which is able to stream 
raw data continuously, and the output format must be such 
that it can be modified or used without any proprietary 
restrictions. 

2. Transceiver Subassembly 

The radio had proven to be a very capable radio as far 
as durability. The previous application for this radio was 
as a tracker, placed on different assets such as vehicles, 
aircraft, and personnel. The position of these tracker- 
equipped assets was then able to be displayed within the 
larger RAPIDS C2 picture. From a technical standpoint, the 
Wolfpack radios were a logical choice since they had already 
been tested, somewhat within the CONOPS context, and members 
of the team were already familiar with their operation. The 
main two detractors from the Wolfpack radios were that the 
radios had never been used in as dynamic a situation as the 
CONOPS demanded, and it still did not resolve the longer 
range problem of not adding undo equipment to heavily laden 
combat troops. 

a. Achievements 

The radios were tested for range and were able to 
achieve greater than 25 km at 5 Watts. No further range 
testing was conducted for the BioRAPIDS application as the 
CONOPS requirements were for a deployed group of soldiers 
that would presumably be at greater distances from the 
command center. At that point, other relay options are 
required, such as using a satellite link to backhaul 
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information. Locally, the range required for the Wolfpack 
radios is for intra squad communications and would have 
lesser range requirements. 

Secondly, the heart rate data from the TZ Max-100 
was able to be passed from the deployed transceiver, and was 
received and properly viewed on the receiving computer. 
This is not a great feat onto itself, but it verified that 
the Wolfpack radios could transmit uncorrupted sensor and 
GPS information from one to the other. 

b. Problems 

Battery life was approximately 12 hours during 
normal operations. A longer battery life is required, since 
troops are deployed for multiple days, and the burden of 
carrying additional batteries is not an option. The goal 
for BioRAPIDS is to have one week of transmissions, with 
charge, at a 5 minute chirp interval. Secondly, there were 
various problems with the form factor of the transceiver and 
its controls. The radio is relatively large in size (.9x3x9 
inches), the toggle buttons risk inadvertent, and it 
contains several bright visual indicators that could divulge 
the wearer's location. These are all physical attributes 
that had been identified prior to testing but had not been 
corrected when testing commenced. 

c. Testing Feedback 

The size of the radio must be reduced to the 
smallest form possible. Controls must be modified to 
prevent inadvertent actuation and to determine if lights 
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need to be removed for operational security. Battery life 
must be extended to comply with project requirements. 



Figure 23. Wolfpack Radio with 6" Ruler Reference 



Figure 24. Wolfpack Radio (top view) 

3. GUI Subassembly 

The GUI was not available for testing during FEX I. 
According to project milestones, the first requirement for 
the GUI is during FEX II. During the EEX I timeframe. 
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further planning was conducted and a requirements document 
was finalized. The proprietary GUI of the TZ Max-100 was 
not seen as a viable option as it would require a completely 
new application to be opened by the operator monitoring the 
deployed troops rather than integrating into the existing 
RAPIDS display. 

Figures 25 and 26 show a preliminary look of the 
BioRAPIDS GUI; the first as an independent sensor with an 
alert condition and the second as one system within a sensor 
system of systems display. At this point, this was all 
simulated without actual data being transmitted through the 
network. 



Figure 25. BioRAPIDS GUI w/ Asset Bio-Alert 
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Figure 26. BioRAPIDS GUI w/ Multiple Asset Display in 

3D, and Asset Manager Tree View w/ Grouped Assets 


In contrast. Figure 27 shows the commercial GUI for the 
TZ Max-100. A good display when used in a fitness 
monitoring applications and provides quite a bit of analysis 
capability as far as personnel performance and historical 
data; but, without the ability to modify the information 
contained in that GUI for a more military application, it 
serves no utility for BioRAPIDS. Such a complicated display 
would not provide quick reference actionable information. 
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Figure 27. Acumen TZ-Max 100 GUI 
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c. 


COASTS FEX II EVENT-CAMP ROBERTS, CA (JANUARY 2009) 


The events at FEX II mirrored those of FEX I. Based on 
the results from FEX I, there was a change to the sensor 
being used, a new radio, and a completely new approach to 
the interface between sensor and radio. These adjustments 
impacted the interface between radio and GUI and required 
additional work to the message transmitted, how it is 
created and where/how the inputs are gathered. The time 
between FEX I (20-31 Oct) and FEX II (20-31 Jan) allowed 
approximately 10 weeks to incorporate the required changes. 
It of interest to note that due to the holiday season 
encompassing Thanksgiving, Christmas, and New Year, delays 
were encountered due to longer shipping times, business 
closures, and personnel schedules. Time delays 
notwithstanding, all resources were maximized and an almost 
complete new system was ready for baseline testing by 
January. 

An additional obstacle that would not be overcome was 
the availability of the RAPIDS system. The management 
architecture of RAPIDS was undergoing an upgrade to the way 
it handled sensor input and fusion. Due to this upgrade, 
BioRAPIDS would not be tested within the RAPIDS network, 
only as a standalone system. The following are results from 
FEX II testing. 

1. Sensor Subassembly 

FEX II saw the introduction of the Numetrex wearable 
bio-monitoring shirt. A complete description of the product 
can be found at the company's Web site ( www . numetrex. com ) . 

The shirt is made of a lycra form fitting type material 
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with two sets of woven sensor fibers at approximately the 
middle of the torso (left and right sides) to sense heart 
beats. Attached to the two sensor strips is a Polar® 
transmitter, which sends the heart beat count to an 
associated receiver, wirelessly. The receiver is then 
hardwired into a USB event counter, manufactured by 
Advantech, INC., which converts the individual heartbeats 
into a rate by relating the individual events into a 
frequency. Once the heart rate is determined, it is 
transmitted to the ultra portable OQO computer via a USB 
cable. The computer then takes the data and formats it into 
the required $PRAVEB message. Once the sensor data is 
formatted, the message is pushed out to the transceiver 
assembly for transmission. This is a radically different 
configuration, as the first iteration did not include the 
sensor's transmitter/receiver components, the event counter 
component or the ultra portable computer for processing. 



Figure 28. Ultra Portable Computer 
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Figure 29. Numetrex Bio-monitoring Shirt 



Figure 30. Advantech Event Counter and Polar Receiver 

a. Achievements 

Much like FEX I testing, all components were first 
tested independently to establish a baseline of operability. 

(1) Sensor Component. The first component 
tested was the shirt sensor. Since this is a commercially 
sold product with demonstrated success, this was more of a 
test to see whether our particular shirts were operable. 
The shirt was tested with minimal activity, increased to 
walking, to light jogging, and then through the recovery 
back to a resting heart rate. When compared to manual 
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measurements, there was no significant difference in the 
readings and therefore the shirt was ascertained to be 
working properly. Two shirts were obtained for this event, 
and one of the shirts proved to be defective and required 
return to the manufacturer. 

(2) Receiver/Counter Assembly Component. 
The receiver/event counter assembly was tested next, and was 
first done so with a wireless simulator unit that came with 
the Polar equipment. By using the simulator first, a know 
signal could be sent to the receiver unit verifying it with 
a known signal rather than an unkown changing heart rate. 
Although the simulator did not have the capability to input 
exact numbers for the heart rate, the operability was tested 
by noting rise and fall as the heart rate was increased and 
decreased, the ability to maintain a steady frequency when 
the simulator was untouched, and a zero reading when the 
simulator was turned off. All functions described above 
were performed satisfactorily by the receiver counter 
assembly and displayed the raw frequency data on the counter 
program. 

(3) Processor Component. Lastly was the OQO 
operability test. This consisted of nothing more than 
turning on the computer and determining whether it was 
functioning. The software/processing test to determine 
whether the OQO properly formatted the sensor data, would be 
performed once the entire sensor subassembly was tested. At 
this point, there were no problems with OQO functionality. 



b. Problems 

(1) Sensor Component. One of two sensor 
shirts did not function. The shirt was tested with multiple 
transmitter and receiver configurations to no avail. No 
signal was received from the inoperable shirt either at the 
receiver/counter assembly, or locally, at a watch receiver. 

(2) Receiver/counter Assembly Component. 
Assembly requires ruggedization in order to be tested in a 
CONORS based test. Currently, receiver board and connector 
wires are extremely susceptible to environmental and 
physical damage, due to a lack of protective casing. A 
longer-term problem is that receiver/counter assembly is 
relatively large and would add significant bulk to a user's 
load-out. 

(3) Processor Component. OQO seemed to get 
extremely hot when in use; it adds added weight and bulk to 
the system; and inserts an added possible point of failure 
for the system. Battery life is unknown under normal 
operating conditions. 

c. Testing Feedback 

(1) Sensor Component. Additional shirts 
need to be acquired in order to replace faulty one, and also 
to conduct testing in a multi-sensor environment. Identify 
subjects to be used for testing in order to acquire the 
correct shirt sizes. Determine the shirt's water resistant 
properties in order to conduct "wet" testing. 
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(2) Receiver/Counter Assembly Component. 
Create casing for receiver counter assembly in order to 
conduct more physical CONORS related testing. 

(3) Processor Component. Investigate 
operational temperature parameters for computer to ensure 
that it will be able to operate in the extreme 
humidity/temperature environment of Thailand. Determine 
extent of battery life. 

2. Transceiver Subassembly 

The second step in the signal flow chain is the ability 
to transmit data back and forth from sensor node to command 
base station. This was the first test of the upgraded 
Wolfpack radios, now Wolfpack II. The radio was modified 
mainly in the form factor and not performance. The case 
itself was now much smaller, the controls had been changed 
from toggles to push buttons that required actuation for 2-3 
seconds in order to activate, operational lights were 
changed to a much dimmer LED, and the antenna was a much 
shorter omni-directional one. 



Figure 31. Wolfpack II Radio 
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Range testing was done with both antennas to determine 
the advantages of one over the other. This test was 
conducted to uncover any possible signal issues using two 
different antennas. The Wolfpack II radio was outfitted 
with one antenna and then driven away from the base station. 
The trip back to the base station was conducted along the 
same route with the second antenna. The data was compared 
for signal strength of the two antennas and showed that 
there was no conclusive evidence to show that either antenna 
was beneficial over the other. In Figure 32, the values 
shown are the signal strength from both antennas at one 
particular location (i.e., the -lOldBm reading was for both 
antennas at that location as were the -lOSdBm and -SOdBm 
readings). 
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Achievements 


a. 

To test radio function, a port was opened using 
Windows HyperTerminal application to communicate between two 
radios. Figure 33 shows the successful transmission of data 
between two radios. This transmission consists of raw 
$PRAVE messages. In accordance to the Wolfpack II technical 
manual (WOLPACK Manual, Oct 2008), this message is sent out 
of the WOLFPACK II when it is operating in the GPS 2 mode. 
It is used by PC applications for tracking location and 
status information. 


Field 

Usage 

Comments 

1 

$PRAVE 

Raveon Proprietary Header 

2 

From ID 

The ID of the transponder that transmitted its 
position over the air. It is a decimal number, 0 
- 9999 . 

3 

To ID 

The ID that this position report was sent to. It 
is a decimal number, 0 - 9999. 

4 

Latitude 

dddmm.mmmm format. It is signed. + is north, - 
is south. No sign means north. Note: typically 

there are 4 decimal places, but as few as 0 
decimal places are possible. Null field if no 

GPS lock. 

5 

Longitude 

dddmm.mmmm format. It is signed. + is east, - is 
west. No sign means east. Note: typically there 
are 4 decimal places, but as few as 0 decimal 
places are possible. Null field if no GPS lock. 

6 

UTC time 

The UTC time at the time the transmission was 
made. Hhmmss format. Null field if no GPS lock. 

7 

GPS Status 

0=not valid position. 1=GPS locked and valid 

position. 

8 

Num 

Satellites 

The number of satellites in view 

9 

Altitude 

The altitude in meters. Null field if no GPS 

lock. 

10 

Temperature 

The internal temperature of the RV-M7 in degrees 
C. Typically this is 5-20 degrees above ambient. 

11 

Voltage 

Input voltage to the device that sent this 
position. 

12 

10 status 

A decimal number representing the binary inputs. 

13 

RSSI 

The signal-strength of this message as measured 
by the receiver, in dBm. Note, if the message 
went through a repeater, it is the signal lever 
of the repeated message. 

14 

Speed 

The speed of the device in km/hour, 0-255 

15 

Heading 

The heading of the device 0-360 degrees 

16 

Status 

Status flags received from the device. Not all 
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products support generating all status flag 
codes. 

NULL means no alerts. 

"P" means a proximity alert. 

"M" means man-down alert 

"A" General alert, usually due to pressing an 
alert button 

"C" Critical alert, usually due to pressing and 
holding alert button 

17 

Spare 

A spare field. May be used for UTC date in the 
future. Typically NULL. 

18 


The NMEA end-of-message identifier. 

19 

Checksum 

The NMEA 0183 checksum. 


Table 2. $PRAVE Message components 



Figure 33. 


Raw $PRAVE Message Transmissions 
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b. Problems 

The only significant problem noted was that 
although the new LED indicators were dimmer, they may still 
be bright enough to create an OPSEC concern in a night time 
operational scenario. Considering that many U.S. military 
operations take advantage of the cover of night, this 
requires more investigation as to the extent of the problem 
and into possible solutions. Battery life has not been 
verified. 


c. Testing Feedback 

Radios require testing in a multi-sensor 
environment. Verification of battery life needs to be 
conducted. 

3. GUI Subassembly 

Testing of the display consisted in verifying alarm 
indications with a simulator. Since most of the 
subassemblies and interfaces were not mobile at this point, 
the system alarms were tested without the use of the actual 
sensor input. To verify that the sensor output would 
generate the proper $PRAVEB message, it was tested at rest. 

a. Achievements 

Message transmission verification was conducted, 
both with $PRAVE message to indicate location, and $PRAVEB 
message to indicate bio-status. The $PRAVEB message is 
composed of ($PRAVB= [EROM RADIO ID], [TO RADIO ID], 
[HEARTRATE], [BPSYSTOLIC], [BPDIASTOLIC], [BODY 
TEMPERATURE], [NMEA CHECKSUM]. Eor example: 
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$PRAVB,0001,0001,0,120,60,98.7,*4C. As previously 
described, the current sensor is only capable of measuring 
hear rate; however, a more flexible message format was 
created to accept possible follow-on sensors. Both $PRAVE 
and simulated $PRAVEB messages were successfully transmitted 
via Wolfpack II radio network. The system also successfully 
transmitted both messages when using the sensor at rest. 


Receiver 


Event Ck>unting 



Eigure 34. Receive Node with Actual Sensor 



Receiver 


Simulator 


Digital I/O 


Eigure 35. Receive Node with Simulator 


95 











b. Problems 

No problems were noted in the integrated test that 
had not been identified within the individual components. 

c. Testing Feedback 

Next round of testing will be conducted using 
repeater architecture and using multiple sensors reporting, 
to test an extended multi-sensor networked environment. 

D. COASTS FEX III (EQUIVALENT) EVENT-U.S. COAST GUARD 

STATION MONTEREY BAY, CA (MARCH 2009) 

FEX III was cancelled and an equivalent test was 
conducted during the same time period. This was the first 
completely integrated testing event in which no base lining 
was required for the independent components, as they had 
already been tested. Without a complete FEX III as 
anticipated, the system would not be tested with a fully 
populated RAPIDS system. This means that while BioRAPIDS 
was tested within the RAPIDS management architecture, there 
were no additional sensors to verify how RAPIDS would 
fuse/manage BioRAPIDS with inputs from other sensor types. 
Since this is more a function of RAPIDS, although of 
interest to BioRAPIDS, this omission did not impact 
BioRAPIDS development and testing progress. 

1. Component Testing 

In conducting the testing during this period, no base 
line testing was required of the individual components; 
however, abbreviated operability checks were conducted on 
all the components to verify their function. 
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Integrated Testing 

The testing was conducted within the bounds of the U.S. 
Coast Guard Station in Monterey, CA. All components were 
assembled and dummy radios were deployed to act as multiple 
sensors but only transmitted location $PRAVE messages. One 
radio was used as a repeater for the network, and one radio 
resided with the sensor to provide the bio-status $PRAVB 
information, verify alarm trips, and observe GUI performance 
in a dynamic environment. 

a. Achievements 


Shown in Figure 36 is the raw $PRAVE data from a 5 
radio network. 
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Figure 36. 


Raw $PRAVE data from 5 radio network 


Figure 37 shows an alarm being generated on a high 

heartbeat (simulated) condition across a Woifpack repeater 

architecture network with 11 radios - ten ''sensor" radios 
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and one repeater. Following the simulated test, an end-to- 
end message with a live sensor on LCDR Gutierrez, alarming 
low (Figure 38); and, historical tracks properly iconed with 
a 3D rotated close-up of the CGS at Monterey Bay (Figure 
39) . 



law Messaoe Feed 

Kandler -> Prave 

lESSW^E: SPRAVE,0001,0001,3636.5558,-12153.8<65,183304,2,8,13,26,8.0,1,-127,0,0,,*44 
Handler -> Prave 

lESSAGE: SPBAVE,0002,0001,3636.5614,-12153.8487,183305,1,7,17,26,12.3,0,-127,0,0,,-70 
Handler -> Prave 

{ESSAGE: SPRAVB,0003,0001,129,120,60,98.7,*70 
Handler -> Pravb 

ffiSSAGE: $PRAVE,0004,0012,3636.5636,-12153.8527,183305,1,6,2,36,11.7,0,-127,0,0,,*4C 
Randier -> Prave 

MESSAGE: SPRAVC,0005,0001,3636.5489,-12153.8389,183305,1,9,9,23,11.2,0,-127,0,0,,•4e 


start ' ^^CoinlsControlExa... 


iOi ■ n nF 




_ Configuration Layers 

WTlreaholdManager fly toDestraMn 

IncrMsad HR Valuea 
liepoitance > Severe 
t^vortanoe >t4gh 
I'nportiTKe >8evated 
bnportance >loi« 

:arTni( Rsige > 

Decreased HR Vatues 
Importance > Severe 
loporBnce >Hgh 
Importance >8evated 
bwportince >low 


Figure 37. 


Simuiated High Aiarm Condition with an ii 
Radio Network 
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b. Problems 

In order to maintain an easier reviewing format, 
the problems discovered will be address by subassembly, or 
as an integrated problem to depict integration problems. 

(1) Sensor Subassembly. 

• More shirt sensors need to be purchased in order 
to conduct multiple bio-status sensor testing. 

• Receiver/counter assembly needs a protective 
casing to conduct CONORS based testing. 

• Bad batteries found in OQO and will not hold a 
charge. Need to procure new batteries or identify 
alternate solution for component replacement. 

(2) Transceiver Subassembly. 

• Intermittent errors encountered with multiple 
radios when set at high reporting rates. 

• Messages crash and information is lost. 

• Suspect anticipated firmware upgrade will resolve 
reporting conflicts. 

(3) GUI Subassembly. As this was the first 
extended GUI test, numerous visual errors were found. 

• COT (Cursor on Target) 

• Pop-up window does not show HR data. 

• Toggling is inconsistent (number of clicks 
required to activate varies from time to 
time). 

• Alarm 

• Once alarm condition triggers alarm it 
continues to trigger an alarm at every 
following event, treats as new alarm. 

• Acknowledging alarm does not clear it from 
Alarm table. 

• Display 
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• New version does not have alarm manager to 
set alarm settings. 

• Need ability to re-start channel from 

display. 

• Need layer prioritization to determine what 

should be displayed when multiple icons in 
same location. 

• Header lines/indicator do not change with 

change of direction of person being tracked. 

• Header indicator on mobile unit will randomly 
disappear completely while monitoring. 

• Alert messages and header indicator disappear 
as you zoom in/out. 

• Need an event logger in order to analyze data 
over long periods. 

(4) Integrated System. 

• A method for placing all components on a test 
subject is required in order to make the system 
truly mobile. 

• Cable management must be addressed for wired 
connections between receiver/counter to computer 
and from computer to transceiver. 

c. Testing Feedback 

The next stage of testing requires that CONOPS 
based testing commence. In order to accomplish this phase a 
form of mounting the sensor and transceiver subassemblies 
must be devised. Of particular attention is an enclosure 
for the receiver/counter assembly that will protect the 
component circuitry from the environment with minimal weight 
and size. 


The main focus of the next testing event is to 
test the operability of the system during more physically 

challenging activities, the emphasis will be to test one 

101 



version of the system. Therefore, the urgency to acquire 
additional sensors, and resolve the collision problem 
between radios is not immediately required. Although, if 
both outstanding items are resolved, there is a possibility 
to test multiple sensors depending on the success of the 
individual sensor test. 

GUI testing is a secondary focus in the next round 
of testing. As the system is used more extensively through 
the testing events constant monitoring is conducted to 
detect any glitches in the graphical representation of the 
gathered data. Since the time between this and the next 
testing event is relatively short, only minor corrections to 
the identified GUI issues is expected; but, development and 
refinement must continue in order to verify operability as 
soon as possible and under as many conditions as possible. 

E. COASTS FEX IV (EQUIVALENT EVENT) -KAHEONE BAY, HI / 

SATTAHIP, THAILAND (MAY 2009) 

In conducting the first true CONOPS based experiment, 
the obstacle course of USMC Base at Kaheone Bay, HI was 
used. The use of the o-course provided the necessary tasks, 
which are representative of the physical actions and range 
of motion that is expected in the field. By observing 
system performance under these conditions, the robustness of 
the system can be evaluated and problems with continuous 
monitoring can be discovered. 

Following the Kaheone Bay testing, modifications were 

made to the system in order to improve on the deficiencies 

discovered at the obstacle course. The enhanced system 

configuration was then evaluated at the Royal Thai Navy Base 

in Sattahip, Thailand. This experiment contributed a great 
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deal to determining whether the present sensor was suitable 
for the expected conditions and allow evaluation of 
component placement in different parts of the body. 
Similarly, the casings of the other components underwent 
the environmental and physical stresses representative of 
the CONOPS scenarios in order to evaluate their current 
level of ruggedness and evaluate overall system readiness. 

1. Component Testing 

In conducting the testing during this period, no base 
line testing was required of the individual components; 
however, abbreviated operability checks were conducted on 
all the components to verify their function. 

The problem with OQO operability was not resolved due 
to a backorder status on OQO batteries. In order to 
continue the testing, a General Dynamics Itronix VR2 rugged 
laptop was substituted to conduct the signal processing and 
formatting functions. This greatly altered system 
configuration and added a greater amount of bulk and weight. 

Upon evaluating the impact to the overall testing, it 
was determined that although the original configuration with 
an OQO ultra portable computer could not be conducted, the 
validity of verifying sensor operation and receiver/counter 
casing under added physical stresses could still be 
conducted; therefore, the main focus of the testing event 
could still be completed. 

2. Integrated Testing 

Due to the replacement of the OQO computer, the rig 
used to carry all the components had to be supplemented 
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with a backpack in order to hold the full size VR2 laptop. 
The original rig had the use of a tactical vest, which had 
the required components attached to it. Although not 
completely tactical at this stage, all components were 
secured to it, and cables were run in such a manner as to 
not interfere with the person's ability to conduct 
different physical activities or inhibit their range of 
motion. Figure 40 shows a proposed vest setup. 



Figure 40. Proposed system set-up using OQO ultra 

portable computer 

The actual setup used, with a backpack (Figure 41), 
did make it a bit more difficult to run and conduct the 
various tasks since the gear tended to shift based on the 
motion of the individual. A positive byproduct of this 
last minute alteration was the fact that it did provide a 
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bit more realistic setup, in that any field operator would 
be carrying a pack of sorts. This allowed limited 
evaluation of how the sensor and transmitter would feel 
with relation to the pack's straps and securing points. 



Radio Antenna 


GPS Antenna 


Receiver/Counter 
\ Assembly 

'/ 


w 


Figure 41. Actual Set-up used during Hawaii/Thailand 
Testing with VR2 Laptop in Backpack 

No significant discomfort or interference was noted due 
to the physical characteristics of how the pack lay on the 
person's body with relation to the sensor and transmitter. 

In order to test the sensor functionality, different 
combinations of individual obstacles was used, as well as 
interspersed laps around the entire obstacle course and 
periods of rest to provide a less physical, control activity 
(Figures 42 and 43). The periods at rest were also used in 
troubleshooting efforts and to evaluate sensor performance 
during the body's recovery cycle. 
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Figure 42. Additional Obstacle Course Station 



Figure 43. Moderate Activity Control Events with Local 

Monitoring 


a. Accomplishments 

(1) Hawaii Testing Results (Day 1) . The 
following is a summary of the more applicable runs through 
the obstacle course and control laps. Several additional 
runs were required in setting up the equipment and making 
adjustments due to the use of a different system line-up 
prompted by the OQO failure. 

• Run 1: Conducted a lap run around obstacle course 
to baseline sensor. Heart rate was unchanged 
throughout the entire run; frequency at event 
counter remained locked. Restarted counter 

program and heart rate monitoring resumed. 
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• Run 2: Conducted first Obstacle run. Ran entire 

course. Heart rate stuck at 14 and was unchanged 
throughout. Reset counter program and switched 
sensors and transmitters. Monitoring resumed. 

• Run 3: Same results as above. Heart rate 

remained unchanged during run. Removed receiver 
unit from pelican case and relocated to the kidney 
area of the body, which was closer to the 
transmitter and prevented interference from hard 
plastic case. 

• Run 4: Conducted run of wall and log hop. Heart 

rate fluctuated through the run but appeared low 
based on the level of activity. Comparison was 
done between shirt sensor and manual readings and 
fluctuated from 18% difference at the higher heart 
rate and 3% after a 2-minute rest period. Once 
difference in sensor and manual readings were 
identified. A comparison was done between sensor 
reporting through USB counter and the provided 
Polar watch monitor. This would help determine if 
discrepancy in heart rate was a factor of the 
sensor, the counter component, or a calibration 
issue. 

• Run 5: A lap jog was done around the obstacle 

course and readings between counter reports and 
watch monitor. There was a difference in readings 
ranging from 5-8% with a couple of outliers at 
12%. In this case, the counter read higher than 
the watch monitor, which was the opposite of the 
counter and manual comparison. 

• Run 6: Conducted a one-lap jog around obstacle 

course. At start, counter reporting was 13% 
higher reading than manual. During jog had 
several dropped readings from the sensor-display 
was "0". Once at rest comparison continued 
between manual and counter readings. Majority of 
the readings were within 3% with a cluster of 
outliers around 6-8% difference with the counter 
being lower in the higher discrepancy events. A 
comparison was also done between manual and watch 
monitor, only at the last two readings of the 
event and were found to be at <1% difference. 
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• Run 7: Conducted a run of the obstacle course on 

the wall and logs since this seemed to provide the 
greatest potential for interference on the sensor 
contact due to the physical activity of climbing 
over obstacles. The sensor read consistently 
within a band around 135 BPM during the run of the 
course. Once at rest a comparison was made 
between the counter and the watch monitor. This 
confirmed suspicions that the counter was reading 
low. There was a discrepancy around 11% with a 
max of 15%. A single point comparison was done 
for the last reading between counter, watch, and 
manual. This yielded a max difference between 
counter and watch of 4% and the lowest difference 
of 2% between counter and manual. 

(2) Hawaii Testing Results (Day 2) . During 
day two, attempts were made to relocate the receiver closer 
to the transmitter; but with the receiver inside the case, 
reception was spotty at best. Various configurations were 
attempted to no avail. The receiver counter assembly was 
then removed from protective casing and placed directly 
inside the backpack and monitoring seemed to be accurate 
while at rest. However, without any protection, receiver 
board and connecting wires could easily be damaged if 
additional activity was done. 

The testing concluded when the VR2 shutdown 
due to overheating and lack of proper ventilation inside 
the backpack. Temps for the day were in excess of 90F with 
heat index. 


(3) Sattahip, Thailand Testing Results. 
Testing conducted in Thailand was much more short lived and 
less extensive than the one conducted in Hawaii. Based on 
the results from the Hawaii testing, there were two main 
problems to overcome in order to continue CONORS testing. 

First was to find a way to provide cooling to the VR2 
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laptop. Second was to find a way in which the 

receiver/counter assembly could be protected without 
interfering with the signal from the sensor transmitter. 

Since the testing team moved directly from 
Hawaii to Thailand the day after the tests concluded in 
Hawaii, time was extremely limited in which to find a 
solution. Once in Thailand, resources and the ability to 
search for alternatives was also limited due to our remote 
AO. 

No solution was found for cooling the 
laptop, therefore; it was agreed that pauses could be 
inserted into the training in order to remove the laptop, 
shut it down and allow it to cool, based on the day's 
weather. 

As for the transmission problem with the 
casing, copper braiding and snaps were used to create an 
extension to the connection points for the sensor 
transmitter. This would allow moving the sensor 

transmitter from the middle of the chest and to the inside 
of the receiver/counter case, therefore, reducing the 
transmission distance between both components to mere 
centimeters . 

Once the system was assembled and testing 
commenced, the readings provided were extremely sporadic 
with "0" dominating the bulk of the readings. A check was 
done on the copper braiding extensions that had been 
adlibbed. A multi-meter confirmed the thought that the 
connections were inadequate. When tested end to end, the 
resistance of the extensions fluctuated from infinite 

resistance to .1 mD . Various attempts were made to 
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tighten and adjust the connectors, but all attempts were 
unsuccessful. 

b. Problems 

Despite the seemingly dismal operational results, 
this first CONOPS test proved to be extremely successful. 
It showed system operability with light physical activity 
and identified specific shortcomings to focus further 
development prior to escalating the physical demands of 
field testing. 

(1) Sensor Subassembly. 

• Unable to transmit to receiver unit through 
protective casing. 

• Transmitter location in middle of the chest 
appears to be too distant from receiver unit. 

• Readings reported from counter via network are 
inconsistent with manual readings and those at 
local receiver. 

• Full size laptop overheats in current enclosure, 
and adds significant weight and bulk to system. 
OQO computer inoperable. 

(2) Transceiver Subassembly. No problems 
encountered with either receiver or transmitter. 

(3) GUI Subassembly. No testing was done on 
GUI; refinement is in progress and tested at next testing 
event in July 2009. 

c. Testing Feedback 

The following are items that need to be addressed 
prior to the next field experiment. 


110 



• OQO needs to be repaired, or comparable substitute 
needs to be identified. 

• Sensor transmitter and receiver need to be 
collocated inside protective case via reliable 
connections to minimize transmission problems and 
maintain the protective properties of the Pelican 
case. 

• Cause for reporting discrepancies between counter, 
local, and manual readings must be identified. 

• Sensor and transceiver subassemblies need to move 
back toward the smaller form factor arrangement of 
the tactical vest. 

• GUI development must be completed to reevaluate 
performance and functionality. 

• BioRAPIDS must be integrated into the broader 
RAPIDS architecture to test performance in a 
varied sensor environment. 

• Additional BioRAPIDS systems must be assembled to 
test multi sensor operability. 


F. CRIMSON VIPER-SATTAHIP NAVAL BASE, THAILAND (JUL. 

2009 ) 

The testing conducted at the Royal Thai Navy Base in 
Sattahip, Thailand replaced the originally scheduled COASTS 
FEX V, which was scheduled at the same location. In this 
latest iteration of testing, the focus was to upgrade the 
receiver counter component, identify and test a new 
processing computer, and evaluate the current status of GUI 
development. The approach was to throttle back the more 
extreme CONORS based testing and concentrate on a system 
that was more reliable and mobile with moderate to heavy 
activity such as jogging, but not as extreme as an obstacle 
course. The results gathered in the last round of testing 
in Hawaii demonstrated various reliability issues that 


111 



needed to be addressed prior to fully attacking the CONOPS 
based tests. 

1. Sensor Subassembly 

This subassembly continues to be comprised of three 
main components the sensor component, receiver/counter 
component, and the processing component. Each will be 
addressed separately and integration points will be 
discussed in the overall system assessment. 

a. Sensor Component 

Thus far, the Numetrex heart monitor is the best 
suited component that has been found. Not to say that it is 
not without limitations, however, for the purposes of a 
proof-of-concept / alpha prototype, it meets all 
requirements. 



Numetrex Shirt with 
woven sensor band 


Local HR monitor 


Polar sensor 
transmitter 


Figure 44. NUMETREX Heart Rate monitoring shirt 

(1) Achievements. It accurately measures 
heart rate, and does so at a cost that is not prohibitive 
within the program budget. 
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(2) Problems. The two main problems 

associated with this sensor is that it is susceptible to 
damage with prolonged exposure to water or submersion. 
Secondly, the transmitter, which is located in the middle of 
the chest, is not the ideal location in a CONOPS sense. By 
being in the middle of the chest, it is in an area that 
typically can receive impact from climbing or crawling, and 
is also in an area that can interfere with other equipment, 
such as pack straps, placement of weapons, etc. Some 
attempts were made to relocate the transmitter to a better 
location, such as the back of the neck, by using braided 
copper wiring to create an extender. None of the attempts 

were successful due to the low voltage of the signals, and 
the large amount of signal loss in the improvised 
connectors. 

(3) Testing Feedback. Conduct testing with 
sensor to determine limits of water exposure in order to 
evaluate whether a new sensor is required. Continue to 
explore means to relocate transmitter to an area that is not 
as impacted by other equipment placement or types of 
physical activities. 

b. Receiver / Counter Component 

Perhaps the most significant advancement for this 
round of testing was the use of a smaller counter USB event 
counter produced by J-Works, Inc. vice the previously used 


This is based on manufacturer specifications, and has yet to be 
tested by the BioRAPIDS team to determine exact limits. 
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Advantech event counter. It is a very simple product that 
counts the individual heart beats received by the receiver 
chip, and then transmits that count to the processor unit 
(computer) via a usb connection from which it is also 
powered. 



Figure 45. Receiver / Counter component size comparison. 

J-Works Counter component (Left) Advantech Counter 

component (Right) 

(1) Achievements. Two things were achieved 
by using the new J-Works JSB-502 Event Counter. First was 
the fact that it greatly reduced its form factor, as seen in 
Figure 45 the size is much smaller when compared to the 
Advantech counter assembly. This not only reduced the size 
of the component, but also reduced the weight from several 
ounces to less than 20 grams. Secondly, a different type of 
enclosure was used to use the J-Works counter, vice the 
Pelican case that was previously used; the new enclosure was 
a simple plastic Project enclosure from Radio Shack 
(3x2x1"). The reduced form factor allowed placement of the 
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receiver / counter assembly closer to the sensor 
transmitter, and the transmission problems found in the 
previous round of testing were eliminated. 

(2) Problems. The new enclosure is not as 
rugged as the Pelican case. It is not as resistant to water 
or shock. 

(3) Testing Feedback. Enclosure must be 
sealed with glue / caulking to prevent water intrusion. 
Internally, receiver and counter circuit boards must be 
permanently mounted to minimize effect of shock. 

c. Processor Component 

Some strides were made to minimize the problems 
encountered while using the VR2 rugged laptop; however, 
final selection of this component still requires more 
exploration. 

(1) Achievements. The Itronix rugged tablet 
used for this round of testing reduced the size and weight 
of the previous iteration by a significant amount. It 
performed with 100% reliability during all testing 
evolutions. New logic was created to accept new counter 
input and convert the raw heart beat count into a rate and 
process into the required RAPIDS message format. 

(2) Problems. Despite the fact that the 
Itronix tablet reduced the form factor of the processing 
computer, it is still significantly larger than the ultra¬ 
portable OQO. As seen in Table 3, the relative differences 
between the various computers is significant, and something 
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in the same category as the OQO ultra-portable computer is 
the best option to reduce size and weight. 


OQO 

VR2 Laptop 

Itronix Tablet 


6.2 lbs. 

3.7 lbs. 





lOin X 12m x 2.24in 

10.6m X 7.2in X 1.65m 

Dimensions 




Table 3. Processing computer physical comparisons 


Testing Feedback. The current need for a 
computer to be carried by every individual wearing the 
BioRAPIDS sensor is an unrealistic requirement, unless the 
computer is small enough to minimize the added weight 
expected to be carried by a soldier. Also, in using a full 
size computer would greatly raise the cost of the system 
with additional capabilities that are not needed. A 
suggestion is to look at manufacturing a small 
microprocessor board and incorporate into the receiver / 
counter housing. This will ensure that the processor only 
addresses the conversion of heart beats into a rate and then 
formatting the information into the required message format. 

2. Transceiver Subassembly 

No problems were encountered with either receiver or 
transmitter. Some limitations were discovered when not 
using an elevated repeater architecture; however, these are 
more RF propagation limitations due to line of sight issues 
rather than a problem with the transceiver itself. 
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Achievements 


a. 

Able to track an individual at approximately 1km 
when using a repeater architecture. The repeater was placed 
on top of a radio tower, at approximately 150ft above 
ground, therefore eliminating line of sight limitations in 
the area of operations. 

b. Problems 

There were no significant problems noted with the 
transceivers performance under the testing conditions. 

c. Testing Feedback 

There were no significant problems found, but it 
is suggested that BioRAPIDS incorporate a GOTS communication 
system, such as Harris tactical radios or PRC-113 tactical 
radio, as soon as able in order to incorporate the system 
with existing fielded systems, rather than stove piping 
another standalone communications device. 

3. GUI Subassembly 

This was the first real test of the GUI since the 
initial trials in March 2009. Overall, the system functions 
well, and the required alteration are minor and largely 
cosmetic in nature. The testing conducted was to determine 
its integration and also to test the functionality with 
respect to specific BioRAPIDS features. 
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Figure 46. BioRAPIDS Display with High Heart Rate Level 

Alarm 


a. Achievements 

GUI integration and operability functioned 
adequately with minimal quirks. The icon of the individual 
was properly displayed and tracked throughout the testing 
evolution. Alarm set points were also tested by manually 
changing the set points at the control node and observing 
whether they would change color based on what threshold was 
crossed. This was found to be the case both as heart rate 
was elevated with increased activity, and also as the heart 
rate lowered with a rest period. Figure 46 shows the 


tracking of an individual as he was running away from the 
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command center. The green leader preceding the individual 
is his speed vector, and the orange dots behind him 
represents the historical track; both are customizable as to 
the time span that the cover. To the right of the screen 
capture is the customizable alarm set points. The icon in 
this case was made to a larger scale to facilitate testing 
and bservation, and will be scaled back when being displayed 
in a denser sensor environment. Figure 47 shows the alarms 
triggered and is also the acknowledgement area, when the 
alarm is clicked, the alarm on the screen will clear. 
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Figure 47. 


BioRAPIDS Alarm History 


b. Problems 


version 


The 

1.1.7 


following discrepancies 
performance. 


were 


noted on GUI 
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• No way to delete a fixed asset, such as tower or 
building. A feature was added to asset right 
click popup in version 1.1.6 but application locks 
when used, the asset is removed upon application 
shut down / restart. 

• Heading Vector lines appear on a fixed assets. 
There is no need for this and should not display 
since those assets will not move. E.g. JOCC, TOWER 
etc. 

• Pause a channel and then un-pause does not 
close/open port but appears to stop the parser 
only forcing an application shutdown/startup to 
make that happen. 


• The only way to acknowledge an alarm is via the 
alerts details tab, a button will be added to the 
popup window when that feature becomes available 
in a future release. 


• Group feature - the assets are not removed from 
the group when the "remove from group" option is 
selected until the next message is processed for a 
group asset. Therefore the asset appears to still 
be active until the next round of reporting. 


• When inadvertently adding a fixed asset with the 
same name as an existing one, such as tower 
included twice, the application locks up and Java 
crashes. Ideally names are just metadata and not 
keys for the Assets and stored as a property 
allowing for dups. A check will be added to 
ensure a duplicate asset name cannot be used, an 
error message will be displayed, currently the 
Name / UID is the primary key for an asset in the 
data base, at this point that field / COT value is 
the only unique element in the system. 

• After restarting RAPIDS no assets appear in the 
asset list. Must Right-click "Assets" -> "create 
New" to add the existing assets. The complete 
list of available assets should appear 
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automatically on restart on both Asset Tree window 
and the 3D display. Currently the asset tree does 
display; however, asset icon still does not 
display in 3D world, user must Edit->OK asset to 
get icon to display in 3D frame. 

c. Testing Feedback 

Continue to refine GUI display and functionality. 

4. Integrated Testing 

The fact that each subassembly and components performed 
well at this stage of testing, does not guarantee that the 
integrated system will function in a similar manner. Due to 
the integration points, the whole is not always the sum of 
its parts. In this case, fortunately, everything functioned 
as desired after being integrated. Figure 48 shows the final 
integrated equipment configuration for the BioRAPIDS system. 



Figure 48. Crimson Viper Integrated BioRAPIDS set-up. 

Testing volunteer HMl (FMF) Jared Castro demonstrates 

the various profiles. 
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Achievements 


a. 

With the current requirement to have a relatively 
large and heavy laptop to process the sensor data, one of 
the challenges toward making the system mobile is the 
stability of the computer during physical activity. For 
this testing event a Helena Camelback hydration pack was 
used to accommodate all the components and secure as tight 
to the body as possible, without restricting mobility. This 
worked extremely well and no adverse comments were noted 
from HMl(FMF) Castro, who actually ran with the BioRAPIDS 
system. All other components were also able to be placed in 
a manner that maximized the sensor / counter components' 
proximity to the sensor transmitter, and allowed the 
transceiver to have unobstructed exposure for its GPS 
assembly and radio antenna to be able to transmit and 
receive RF signals. 

The overall system was easily employed and was 
able to track the individual while deployed away from the 
command node. The display alarms were properly triggered 
when the individual's heart rate reached the user customized 
setpoints. 


b. Problems 

There are two main problems with the BioRAPIDS 
system. First is in the interfaces between the receiver / 
counter component and the processor (USB cable), and between 
the processor (computer) and transceiver (RS-232 cable). 
While this test did not directly show a problem with these 
interfaces, the relative ease by which a USB cable can be 
disconnected does not bode well for its reliability in a 
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full CONOPS based situation. Regardless how well the cable 
management is done, accidental disconnection seems highly 
probable. 

The second problem is the requirement for a 
computer to process the sensor data. Aside from the added 
cost and weight of this device, it adds and additional 
failure point, and in the author's opinion, unnecessarily 
so. 


c. Testing Feedback 

In addressing the noted weak points the following 
is recommended. To fully address each of the issues, both 
have to be worked simultaneously. Perhaps the best solution 
for solving both issues is to create a combined housing for 
the sensor receiver and counter / processor circuit boards. 
This combined housing can then be directly coupled to the 
transceiver, either as an added internal component, or as an 
external attachment that can be rigidly connected to the 
transceiver, therefore eliminating external wires that could 
be accidentally disconnected. 

A similar approach would be to co-house the sensor 
receiver and couter boards, but transmitting the raw data 
through the network. The data processing can be conducted at 
the receive node, which presumably does not have the same 
mobility requirement as a soldier in the field, and 
therefore can easily support the computing requirements. 

G. CONTINUING AHEAD 

Chapter V discusses conclusions regarding the system 
status in relation to the sponsor requirements, and outlines 
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a proposed path to meeting the outstanding requirements by 
the required acceptance test time (Fall 2009) . Along with 
presenting an analysis in respect to the project contract, a 
review of the thesis questions is conducted, presenting the 
findings based on the BioRAPIDS development process. The 
chapter concludes by exploring the benefits of the system 
beyond the requirements of the BioRAPIDS contract and 
provides possible areas for continued study. 
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V. 


CONCLUSIONS AND RECOMMENDATIONS 


The first portion of this chapter addresses the 
proposed research questions outlined in Chapter I. The 
primary thesis question is addresseded first, followed by a 
discussion of the secondary questions (that were proposed in 
Chapter I) and the extent to which they were explored. A 
brief explanation of areas that were not explored is 
conducted, as well as suggested follow-on research in this 
field and follow on system iterations. 

Beyond the thesis discussion, conclusions will be 
drawn regarding the system status in relation to the 
sponsor requirements, and will outline a clear path to 
meeting the outstanding requirements by the required 
acceptance test time (Fall 2009). Lastly, the chapter will 
explore the benefits of the system beyond the requirements 
of the BioRAPIDS contract. 

A. PRIMARY THESIS FOCUS 

In exploring the need presented by the sponsor, the 
main focus of this thesis was to explore how a system could 
be configured to enhance situational awareness through 
multiple layers of command and control with the use of 
networked personnel monitoring devices. 

To meet this goal, the BioRAPIDS system was developed 
and demonstrated as a proof of concept prototype system (the 
alpha prototype is a deliverable for January 2009) . 
COTS/GOTS technologies were acquired and adapted to create a 
system to monitor and report the bio-state and GPS location 

of an individual deployed away from a command center. To 
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display this information, a GUI was created. The GUI allows 


BioRAPIDS to function as a standalone system, or be 
integrated into the broader RAPIDS sensor fusion/management 
network (RAPIDS was developed through previous NPS 
research). The GUI's purpose was two-fold: 1) to display 
the information sent by the sensor, and 2) to organize this 
information in a way that would show sufficient fidelity to 
make it useful, but not overwhelm the user. 

The BioRAPIDS system was divided into three main 
subassemblies, which were then integrated and tested within 
a spiral development model to make alterations as needed and 
determine the systems limitations and capabilities. To make 
conclusions regarding the current status of system 
development an integrated assessment will be made based on 
the overall system requirements listed in the system 
requirements document (Requirements, Sep 2008). 

1. User Interface Requirements 

Taken from the requirements document, these are the 
original requirements for software development that would 
make up the GUI. Outlined here are the outstanding 
requirements and any suggested plan of action in order to 
meet them. 


a. Status Assessment 

The specific requirements that have not been met 
by the user interface are explicitly explained in Chapter IV 
Paragraph E.S.b (Crimson Viper 2009 Test Results). The user 
interface requirements, which have not been met, are 
relatively minor in scope and address the look/feel of the 
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interface, rather than a glaring lack of functionality. The 
testing conducted during Crimson Viper 2009 (July 2009) was 
the first real test of the GUI after the initial shakedown 
completed in January 2009. A significant event that has 
added to some of the discrepancies is the ongoing upgrade to 
the larger RAPIDS system architecture. With changes to the 
RAPIDS management architecture, interfaces between BioRAPIDS 
and RAPIDS require further refinement in order to avoid 
glitches between the old and new interfaces. 

Jb. Recommendations 

Based on the BioRAPIDS timeline (BioRAPIDS 
Schedule Sep 2008), interface development is well within the 
required milestone deadline. Final delivery of the 
completed GUI is scheduled for January 2010. Therefore, 
based on the current status of the user interface 
development, it is recommended that development and 
refinement continue as planned. A suggestion for the next 
field test is to dedicate a day for GUI manipulation with 
various users operating the GUI to determine short falls in 
capability or glitches in performance. Based on current 
operability and assuming that the identified issues are 
corrected prior to the next testing event scheduled for 
October 2009, any remaining issues will only be found with 
extensive manipulation of all the required functions of the 
user interface. 

2. Biometric Sensor Requirements 

The biometric sensor requirements (Requirements, Sep 
2008) pertain to the capability and functionality of the 
sensor and transceiver subassemblies. These requirements 
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are also impacted by the CONOPS requirements, which will 
dictate how the system will be used. The CONOPS 

requirements inject additional intrinsic requirements that 
go beyond basic technical capability. Although not 

explicitly quantized, concerns such as form factor and 
ruggedness need to be addressed here. 

a. Status Assessment 

Currently, there is only one outstanding technical 
requirement that is not met. It addresses the inability of 
the sensor to measure multiple parameters: Heart Rate (HR), 
Breathing Rate (BR), Skin Temperature (T) , Posture (P) , 
Activity (A) as outlined in the requirements document 
(BioRAPIDS Requirements Sep 2008) . Based on current funding 
and the cost of suitable sensors to meet these requirements, 
it is unlikely that this requirement will be met. 
Therefore, either more money will be required to obtain one 
of the more advanced sensors, or the sponsor will need to 
accept the shortfall. 

Based on the overall requirements of the system, 

it seems more logical to have only the heart rate parameter 

represented at this point. To include the other four 

parameters listed in the requirements document, for any of 

the deliverable prototypes, would result in two conditions. 

First, if the information of the advanced sensor were all 

displayed (HR, BP, Temp, Respiration Rate, etc.), a person 

monitoring the display would be overwhelmed with too much 

information and the conclusions that could be made by a 

typical watchstander would not add appreciable value. 

Secondly, if all of these measurement values are required, 

the development of an algorithm is required to aggregate 
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this information, with proper weighting factors, and display 


a consolidated "health status" rather than the specific 
parameters. 

To satisfy the intent of the system, which is to 
monitor life and death conditions, and be able to make "back 
of the napkin" assessments to the overall health status and 
possible fatigue, heart rate alone is sufficient at this 
point. 


b. Recommendations 

As most of the technical requirements are met at 
this point, the recommendations listed pertain more toward 
the CONOPS requirements. Following are the three main 
recommendations to make the system more robust and be able 
to operate better in a CONOPS dictated environment described 
in Chapter I. 


(1) Survivability Recommendations. 

• Conduct testing with sensor to determine limits of 
water exposure in order to evaluate whether a new 
sensor is required. 

• Continue to explore means to relocate transmitter 
to an area, away from the middle of the chest, 
which will not be as impacted by other equipment 
placement or types of physical activities. 

• Similarly, use sealant to waterproof 

receiver/counter housing and mount circuit boards 
in a manner to minimize shock received by physical 
activity. 

(2) Interface Recommendations. 

• Currently, the need for external USB or serial 
cables to connect the various components poses a 
possible problem with inadvertent disconnection of 
one of these integration points. 

129 



• A suggestion is to create a combined housing for 
the receiver/counter/processor circuit boards. 
This combined housing can then be directly coupled 
to the transceiver, either as an added internal 
component, or as an external attachment that can 
be rigidly connected to the transceiver. 


(3) Reduced Form Recommendation. 

• The need for a full computer to process the heart 
beat data and format into the required system 
message format adds a relatively large and weighty 
component. 

• To minimize the footprint of the processor, there 
are two suggestions. 

• The first, as stated under the interface 

recommendations (in section 2.b.2 of Chapter 
V), is to produce a microprocessor to perform 
the required functions and then integrate 

into a combined receiver/counter/processor 
housing. 

• The second is to transmit the raw data 

through the network, and conduct the data 

processing at the receive node. 

The second recommendation is perhaps the best 

overall, since it would eliminate one component from the 
overall system and would also eliminate a possible failure 
point. 


3. Summary of Suggested System Enhancements 

Overall, the proof-of-concept prototype developed far 
exceeds what could be expected from a lab prototype. It has 
shown to be capable of performing the required system 
functions, although in a limited basis, at a somewhat 
operational level, represented by CONORS based testing. In 
the short period of eight months covered within this thesis, 
a disparate number of unrelated components were brought 
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together to perform the cohesive functions required by 
BioRAPIDS. The next steps leading up to the delivery of a 
working prototype need to concentrate on trying to enhance 
ruggedness, decreasing form factor, and refining GUI 
properties . 

There are only three main suggestions for finalizing 
the BioRAPIDS prototype: I) minimize external physical 
interfaces, 2) enhance physical attributes, and 3) 
incorporate an existing, fielded communications transceiver 
into the testing. As this thesis study only extends to the 
proof-of-concept prototype, there are several more iterative 
development and testing cycles prior to the scheduled 
delivery of the operational alpha prototype and by focusing 
on these areas, the resultant alpha prototype will be 
extremely capable and robust. 

B. SECONDARY THESIS QUESTIONS 

Along with the primary purpose producing a proof-of- 
concept prototype, secondary areas that were also examined 
are the development process of BioRAPIDS, study system 
performance in a variety of environments, and propose future 
implementation. Following are the results of these 
secondary research areas. 

1. Development Process 

The development process was adhered fairly well as 
represented by development model in Chapter II. Perhaps, 
the area that had some variation was the activities of the A 
and B phases. The upfront requirements, specifications, and 
designs that are typical of these phases were not 


131 



necessarily as linear in execution. Based on the broad up 
front requirements ("skunk works" environment) and the fact 
that almost no bottom-up design took place, due to the use 
of COTS/GOTS components, the specifications and interface 
designs were reversed engineered, once the components were 
identified. This of course would not work if the project 
required a bottom up design of the components, since 
engineers would not know what to build. However, in the 
case of BioRAPIDS, a strict design of interfaces and 
components would severely slow the process of identifying 
viable components, since the BioRAPIDS team did not have 
control of the components design and since they are off the 
shelf and already built. By guiding component search with 
broad requirements, it expedited the search and allowed 
greater flexibility in choosing the components. It is 
logical to understand that choosing a component based on 
just one core capability as opposed having to satisfy 
multiple specifications will provide a broader range of 
components from which to choose. Once the main capability 
was satisfied by a particular product, an evaluation was 
made as to the feasibility of interconnecting the chosen 
components and a detailed integration design was created. 

Aside from this variation in the "normal" order of 
systems engineering development, the spiral process was used 
to develop the BioRAPIDS system iteratively, and therefore, 
demonstrate the proof-of-concept prototype in this thesis, 
prior to the alpha prototype due January 2010. 

Overall, the approach was very methodical and efficient 
and brought to light a variation to the model, which can be 
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used when systems are created from COTS/GOTS technology. 
Figure 49^^ explains this concept in a graphic format. 



Figure 49. High Level View of Observed Component 

Selection, Integration Design, and Component 
Integration Process for BioRAPIDS Using COTS/GOTS 

Technology 


2. Environmental Effects on System Performance 

This area was not explored as was initially planned. 
Testing was conducted in various types of environments and 
locations. However, the system was not at a point where 
significant data could be gathered by changing the operating 
environment. The testing thus far has been more focused on 
testing the integration points to yield a prototype with 
sufficient reliability in order to conduct more 
operationally focused testing. 


Model developed by LCDR Gutierrez based on observations made 
during the design process of BioRAPIDS. 
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The system is at a point now where the next round of 
testing could involve more empirical performance related 


testing, rather than the more qualitative operability 
testing that has been the focus up to this point. More 
testing runs can be conducted under varying conditions to 
gather performance data and statistically analyze 
performance measures. 

C. FURTHERING BIORAPIDS 

As refinements are conducted on the current proof-of- 
concept prototype, the next step will be to test the 
enhanced system under more rigorous and strenuous 
conditions. Once the system is optimized, multiple systems 
must be built in order to test in a multi sensor 
environment, and following that perhaps, a higher level 
testing by inserting with real troops into an exercise 
environment, such as Cobra Gold.^^ 

As the system matures, research must be done on 
peripheral areas that will have a larger impact if the 
sensor is actually deployed operationally. First, a closer 
look must be taken at security of the system. Security in 
this case refers to two areas: the first being security from 
spoofing by interfering with the wireless signals or having 
a different individual don the device, and the other 
operational security by examining the susceptibility of 
detection created by the wireless communication of the 


1 

Cobra Gold is a regularly-scheduled joint/combined exercise and is the 
latest in the continuing series of U.S.-Thai military exercises designed to 
ensure regional peace and strengthen the ability of the Royal Thai Armed Forces 
to defend Thailand or respond to regional contingencies. Cobra Gold is one of 
several training exercises the United States conducts with Thailand each year. 
The United States funds Thai military and civilian professional development 
training under the international military education and training program (IMET). 


134 



system. 

Secondly, 

an analysis 

of 

frequencies 

must 

be 

conducted. 

This is 

to ensure that 

the system 

does 

not 

induce or receive RF 

interference 

when 

operating 

around 

or 


near existing systems, and also to ensure that proximity of 
two individuals with BioRAPIDS will not adversely affect 
accurate reporting of either system by confusing the input 
signals. Lastly, if the system evolves into a diagnostic 
tool for more advanced health assessments (e.g., respiration 
rate, core temperature, blood pressure, etc.) an enhanced 
algorithm must be developed to analyze the data and not 
burden the operator with that analysis. In order to 
accomplish this, several disciplines must be merged to 
ensure that the product is medically and mathematically 
sound. 

The current BioRAPIDS capability provides a very 
powerful tool for decision makers to assess the status of 
their troops. However, the topics listed above can 
certainly enhance the systems capabilities and further its 
possible use. 

D. FUTURE APPLICATIONS BASED ON BIORAPIDS 

The provided capability will allow for better 
management of forces. Aside from providing positional 
information, the bio-status reporting will give an immediate 
picture of casualties during combat, and with appropriate 
analysis can assist in understanding fatigue and physical 
stress on field troops. As all the available information 
from BioRAPIDS and other sensors is synthesized, strategic 
decisions can benefit from knowing troop strength levels, 
number of casualties, and location of forces, and risk 
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evaluation can be better assessed with real time 
information. 

Although mainly addressing this capability in a 
military context, the applicability of this system can be 
applicable to law enforcement, first responders, and 
commercial exploration. The need to have information 
regarding casualties and location of personnel is equally as 
important as for the non-military sectors. 

With this capability fully developed, it also opens the 
doors to future applications. By having the architecture in 
place, which reports bio-state and position, the addition of 
other sensors such as cameras, biometric devices, and data 
transfer capabilities can advance at a faster pace. By 
having the backbone of the architecture in place, adding 
these new sensors into the architecture consists of only 
developing the interfaces for these devices, rather than 
building the architecture from the ground up. The feature 
extraction and fusion algorithms can be added at the 
BioRAPID system or the RAPIDS GUI. Wireless devices can be 
made to report via standardized protocols and therefore the 
receiver circuit board currently used for BioRAPIDS can be 
adapted to receive additional inputs. 

As portable computing devices become smaller and more 
powerful, the ability to process large amounts of data 
gathered from disparate sensors becomes more attainable to 
the disadvantaged user and allows wider dissemination of 
that information. However, the final frontier that must be 
conquered in order to truly have sensors pervasively 
deployed within a network-centric architecture is 
connectivity and automation of feature extraction/fusion and 
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behavior analysis of sensor data (Goshorn et al. 2009) . 
Means of communication and automated information extraction 
that will eliminate the differences between advantaged and 
disadvantaged users will be the key to truly having a common 
operating picture. 
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